Hi Marc, On 2021/3/12 16:52, Marc Zyngier wrote: > On Thu, 11 Mar 2021 14:28:17 +0000, > Keqian Zhu <zhukeqian1@xxxxxxxxxx> 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 <zhukeqian1@xxxxxxxxxx> 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. > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
