From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1DEBC433E0 for ; Fri, 12 Mar 2021 09:30:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B440E64FE2 for ; Fri, 12 Mar 2021 09:30:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232862AbhCLJaJ (ORCPT ); Fri, 12 Mar 2021 04:30:09 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:13883 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232860AbhCLJ3r (ORCPT ); Fri, 12 Mar 2021 04:29:47 -0500 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4DxgTR1Pjnz8x4g; Fri, 12 Mar 2021 17:27:55 +0800 (CST) Received: from [10.174.184.42] (10.174.184.42) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Fri, 12 Mar 2021 17:29:35 +0800 Subject: Re: [RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO To: Marc Zyngier References: <20210122083650.21812-1-zhukeqian1@huawei.com> <87y2euf5d2.wl-maz@kernel.org> <87o8fog3et.wl-maz@kernel.org> CC: , , , , Will Deacon , Catalin Marinas , Mark Rutland , James Morse , Robin Murphy , Joerg Roedel , Daniel Lezcano , Thomas Gleixner , "Suzuki K Poulose" , Julien Thierry , Andrew Morton , Alexios Zavras , , From: Keqian Zhu Message-ID: Date: Fri, 12 Mar 2021 17:29:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87o8fog3et.wl-maz@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.184.42] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 2021/3/12 16:52, Marc Zyngier wrote: > On Thu, 11 Mar 2021 14:28:17 +0000, > Keqian Zhu wrote: >> >> Hi Marc, >> >> On 2021/3/11 16:43, Marc Zyngier wrote: >>> Digging this patch back from my Inbox... >> Yeah, thanks ;-) >> >>> >>> On Fri, 22 Jan 2021 08:36:50 +0000, >>> Keqian Zhu wrote: >>>> >>>> The MMIO region of a device maybe huge (GB level), try to use block >>>> mapping in stage2 to speedup both map and unmap. [...] >>>> break; >>>> >>>> - pa += PAGE_SIZE; >>>> + pa += pgsize; >>>> } >>>> >>>> kvm_mmu_free_memory_cache(&cache); >>> >>> There is one issue with this patch, which is that it only does half >>> the job. A VM_PFNMAP VMA can definitely be faulted in dynamically, and >>> in that case we force this to be a page mapping. This conflicts with >>> what you are doing here. >> Oh yes, these two paths should keep a same mapping logic. >> >> I try to search the "force_pte" and find out some discussion [1] >> between you and Christoffer. And I failed to get a reason about >> forcing pte mapping for device MMIO region (expect that we want to >> keep a same logic with the eager mapping path). So if you don't >> object to it, I will try to implement block mapping for device MMIO >> in user_mem_abort(). >> >>> >>> There is also the fact that if we can map things on demand, why are we >>> still mapping these MMIO regions ahead of time? >> >> Indeed. Though this provides good *startup* performance for guest >> accessing MMIO, it's hard to keep the two paths in sync. We can keep >> this minor optimization or delete it to avoid hard maintenance, >> which one do you prefer? > > I think we should be able to get rid of the startup path. If we can do > it for memory, I see no reason not to do it for MMIO. OK, I will do. > >> BTW, could you please have a look at my another patch series[2] >> about HW/SW combined dirty log? ;) > > I will eventually, but while I really appreciate your contributions in > terms of features and bug fixes, I would really *love* it if you were > a bit more active on the list when it comes to reviewing other > people's code. > > There is no shortage of patches that really need reviewing, and just > pointing me in the direction of your favourite series doesn't really > help. I have something like 200+ patches that need careful reviewing > in my inbox, and they all deserve the same level of attention. > > To make it short, help me to help you! My apologies, and I can't agree more. I have noticed this, and have reviewed several patches of IOMMU community. For that some patches are with much background knowledge, so it's hard to review. I will dig into them in the future. Thanks for your valuable advice. :) Thanks, Keqian > > Thanks, > > M. >