Re: [RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO

Hi Marc,

On 2021/3/12 16:52, Marc Zyngier wrote:

On Thu, 11 Mar 2021 14:28:17 +0000,
Keqian Zhu [off-list ref] wrote:

quoted

Hi Marc,

On 2021/3/11 16:43, Marc Zyngier wrote:

quoted

Digging this patch back from my Inbox...

Yeah, thanks ;-)

quoted

On Fri, 22 Jan 2021 08:36:50 +0000,
Keqian Zhu [off-list ref] wrote:

quoted

The MMIO region of a device maybe huge (GB level), try to use block
mapping in stage2 to speedup both map and unmap.

[...]

quoted

quoted

quoted

 			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().

quoted

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.

quoted

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel