Hi Ganapatrao,
On 2023-09-14 14:10, Ganapatrao Kulkarni wrote:
Hi Marc,
On 15-05-2023 11:00 pm, Marc Zyngier wrote:
From: Christoffer Dall <christoffer.dall@xxxxxxxxxx>
Unmap/flush shadow stage 2 page tables for the nested VMs as well as
the
stage 2 page table for the guest hypervisor.
Note: A bunch of the code in mmu.c relating to MMU notifiers is
currently dealt with in an extremely abrupt way, for example by
clearing
out an entire shadow stage-2 table. This will be handled in a more
efficient way using the reverse mapping feature in a later version of
the patch series.
We are seeing spin-lock contention due to this patch when the
Guest-Hypervisor(L1) is booted with higher number of cores and
auto-numa is enabled on L0.
kvm_nested_s2_unmap is called as part of notifier call-back when numa
page migration is happening and this function which holds lock becomes
source of contention when there are more vCPUs are processing the
auto-numa page fault/migration.
This is fully expected. Honestly, expecting any sort of performance at
this stage is extremely premature (and I have zero sympathy for hacks
like auto-numa...).
[...]
+ kvm_nested_s2_unmap(kvm);
This kvm_nested_s2_unmap/kvm_unmap_stage2_range is called for every
active L2 and page table walk-through iterates for long iterations
since kvm_phys_size(mmu) is pretty big size(atleast 48bits).
What would be the best fix if we want to avoid this unnessary long
iteration of page table lookup?
The fix would be to have a reverse mapping for any canonical IPA to
any shadow IPA, which would allow us to not fully tear down the shadow
PTs but only the bit we need to remove. This is clearly stated in the
commit message you quoted.
However, this plan is pretty far down the list, and I have no plan to
work on performance optimisations until we have basic support merged
upstream.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
