]> www.infradead.org Git - users/dwmw2/linux.git/commit
KVM: x86: First attempt at converting nested virtual APIC page to gpc xen-evtchn-v3
authorDavid Woodhouse <dwmw@amazon.co.uk>
Tue, 16 Nov 2021 16:38:44 +0000 (16:38 +0000)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Wed, 17 Nov 2021 17:15:45 +0000 (17:15 +0000)
commit35ed245ea229add70fc6dfbc90184f2ef322e8ed
treedaff1c911df6aa8a877fa83b5bd9dfb56515474a
parent277ab6290028d23758813996e59f05abe003a2a9
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