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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
