On Fri, 2026-01-02 at 14:24 +0000, Fred Griffoul wrote: > This patch series introduces performance optimizations for nested > VMX workloads with "unmanaged" guest memory.
I've reworked the first half of this on top of the GPC SRCU conversion¹, with the guest-mode pinning done as Sean prescribed²: > IMO, the least awful way to deal with this is to tag > KVM_REQ_GET_NESTED_STATE_PAGES > with KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP, and then pass the specific > request > that needs to be made when invalidating a vCPU-mapped gpc as part of > __kvm_gpc_init() (though maybe call it vcpu_gpc_init()?). https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/nvmx-gpc David Woodhouse (2): KVM: pfncache: Add guest-mode pinning (GUEST_USES_PFN successor) KVM: x86: Post KVM_REQ_GET_NESTED_STATE_PAGES on memslot updates Fred Griffoul (3): KVM: nVMX: Implement cache for L1 MSR bitmap KVM: nVMX: Use pinned pfncache for L1 APIC virtualization pages KVM: selftests: Add nested VMX APIC cache invalidation test The caller of kvm_gpc_init_for_vcpu() gives the specific KVM_REQ to use. Invalidation raises that KVM_REQ and forces the vCPU out of guest mode with a KVM_REQ_OUTSIDE_GUEST_MODE. Both kvm_gpc_invalid() and is_nested_state_invalid() go away, along with the entirety of your patch 3. The pending request *is* the thing that signals invalidity, and the vCPU entry path checks it after setting IN_GUEST_MODE. Testing and review found (and fixed) some issues which are also present in your v4 series... • vmx_has_nested_events() can't refresh: it's reachable from the kvm_vcpu_block() loop under set_current_state(TASK_INTERRUPTIBLE), and a refresh sleeps. Claim a pending event instead and let the bounce through vcpu_run do the refresh. • vcpu_enter_guest() consumes KVM_REQ_GET_NESTED_STATE_PAGES *before* calling the handler. If nested_get_vmcs12_pages() then fails (even the load_pdptrs() early exit) and userspace re-runs the vCPU, it re-enters L2 with the stale address still latched and no request pending. With no page reference held, that's use-after-free. Any failure has to re-post the request. • Stripping KVM_REQUEST_WAIT for !may_block is racy: process_mrelease() reaps while vCPUs still run. The wait is safe anyway (it spins, never sleeps), so just don't strip it. (Not to mention the fact that the prohibition on sleeping is bogus anyway, qv³). • A memslot move under a running L2 never re-resolves the latched addresses at all (true of the kvm_host_map code too), so the CPU keeps writing guest-influenced vAPIC/PI state into a page the VMM thinks it took back. Arguably userspace which does this gets what it deserves, but posting the request from kvm_arch_memslots_updated() is cheap and makes it converge the same way every other stale-generation user does. Your selftest is in the branch (thanks — its madvise mode caught real issues in soak), adjusted for the tdp_map() API churn. I haven't touched the latter half of your series; didn't either Sean or Vitaly suggest it should be a separate series? If not, I'm suggesting it now :) Kicking off some tests overnight... ¹ https://lore.kernel.org/all/[email protected]/ ² https://lore.kernel.org/all/[email protected]/ ³ https://lore.kernel.org/all/[email protected]/
smime.p7s
Description: S/MIME cryptographic signature
