]> www.infradead.org Git - users/dwmw2/linux.git/commit
KVM: x86: First attempt at converting nested virtual APIC page to gpc xen-evtchn
authorDavid Woodhouse <dwmw@amazon.co.uk>
Tue, 16 Nov 2021 16:38:44 +0000 (16:38 +0000)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Fri, 10 Dec 2021 15:48:37 +0000 (15:48 +0000)
commit6c289f68c6e885df3d3b177c06a48efa8299d89c
tree490867bac73b7bb3729b5524812ebac922934a72
parent426c7281f7c7777996e2fee86db9fff58ff50c28
KVM: x86: First attempt at converting nested virtual APIC page to gpc

This is what evolved during the discussion at
https://lore.kernel.org/kvm/960E233F-EC0B-4FB5-BA2E-C8D2CCB38B12@infradead.org/T/#m11d75fcfe2da357ec1dabba0d0e3abb91fd13665

As discussed, an alternative approach might be to augment
kvm_arch_memslots_updated() to raise KVM_REQ_GET_NESTED_STATE_PAGES to
each vCPU (and make that req only do anything on a given vCPU if that
vCPU is actually in L2 guest mode).

That would mean the reload gets actively triggered even on memslot
changes rather than only on MMU notifiers as is the case now. It could
*potentially* mean we can drop the new 'check_guest_maps' function.

The 'check_guest_maps' function could be a lot simpler than it is,
though. It only really needs to get kvm->memslots->generation, then
check each gpc->generation against that, and each gpc->valid.

Also I suspect we *shouldn't* destroy the virtual_apic_cache in
nested_vmx_vmexit(). We can just leave it there for next time the
vCPU enters guest mode. If it happens to get invalidated in the
meantime, that's fine and we'll refresh it on the way back in.
We probably *would* want to actively do something on memslot changes
in that case though, to ensure that even if the vCPU isn't in guest
mode any more, we *release* the cached page.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
arch/x86/include/asm/kvm_host.h
arch/x86/kvm/vmx/nested.c
arch/x86/kvm/vmx/vmx.c
arch/x86/kvm/vmx/vmx.h
arch/x86/kvm/x86.c