Messages in this thread | | | Subject | Re: [EXTERNAL] [PATCH v2] KVM: Don't actually set a request when evicting vCPUs for GFN cache invd | From | David Woodhouse <> | Date | Fri, 25 Feb 2022 16:59:59 +0000 |
| |
On Fri, 2022-02-25 at 16:13 +0000, Sean Christopherson wrote: > On Fri, Feb 25, 2022, Woodhouse, David wrote: > > Since we need an active vCPU context to do dirty logging (thanks, dirty > > ring)... and since any time vcpu_run exits to userspace for any reason > > might be the last time we ever get an active vCPU context... I think > > that kind of fundamentally means that we must flush dirty state to the > > log on *every* return to userspace, doesn't it? > > I would rather add a variant of mark_page_dirty_in_slot() that takes a vCPU, which > we whould have in all cases. I see no reason to require use of kvm_get_running_vcpu().
We already have kvm_vcpu_mark_page_dirty(), but it can't use just 'some vcpu' because the dirty ring is lockless. So if you're ever going to use anything other than kvm_get_running_vcpu() we need to add locks.
And while we *could* do that, I don't think it would negate the fundamental observation that *any* time we return from vcpu_run to userspace, that could be the last time. Userspace might read the dirty log for the *last* time, and any internally-cached "oh, at some point we need to mark <this> page dirty" is lost because by the time the vCPU is finally destroyed, it's too late.
I think I'm going to rip out the 'dirty' flag from the gfn_to_pfn_cache completely and add a function (to be called with an active vCPU context) which marks the page dirty *now*.
KVM_GUEST_USES_PFN users like nested VMX will be expected to do this before returning from vcpu_run anytime it's in L2 guest mode. [unhandled content-type:application/pkcs7-signature] | |