From: Sean Christopherson <seanjc@google.com>
To: Xu Yilun <yilun.xu@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>,
David Matlack <dmatlack@google.com>
Subject: Re: [PATCH 2/3] KVM: Always flush async #PF workqueue when vCPU is being destroyed
Date: Tue, 24 Oct 2023 08:49:24 -0700 [thread overview]
Message-ID: <ZTfnhEocglG1AsO8@google.com> (raw)
In-Reply-To: <ZTd+i2I5n0NyzuuT@yilunxu-OptiPlex-7050>
On Tue, Oct 24, 2023, Xu Yilun wrote:
> On Wed, Oct 18, 2023 at 01:46:23PM -0700, Sean Christopherson wrote:
> > @@ -126,7 +124,19 @@ void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu)
> > list_first_entry(&vcpu->async_pf.done,
> > typeof(*work), link);
> > list_del(&work->link);
> > +
> > + spin_unlock(&vcpu->async_pf.lock);
> > +
> > + /*
> > + * The async #PF is "done", but KVM must wait for the work item
> > + * itself, i.e. async_pf_execute(), to run to completion. If
> > + * KVM is a module, KVM must ensure *no* code owned by the KVM
> > + * (the module) can be run after the last call to module_put(),
> > + * i.e. after the last reference to the last vCPU's file is put.
> > + */
> > + flush_work(&work->work);
>
> I see the flush_work() is inside the check:
>
> while (!list_empty(&vcpu->async_pf.done))
>
> Is it possible all async_pf are already completed but the work item,
> i.e. async_pf_execute, is not completed before this check? That the
> work is scheduled out after kvm_arch_async_page_present_queued() and
> all APF_READY requests have been handled. In this case the work
> synchronization will be skipped...
Good gravy. Yes, I assumed KVM wouldn't be so crazy to delete the work before it
completed, but I obviously didn't see this comment in async_pf_execute():
/*
* apf may be freed by kvm_check_async_pf_completion() after
* this point
*/
The most straightforward fix I see is to also flush the work in
kvm_check_async_pf_completion(), and then delete the comment. The downside is
that there's a small chance a vCPU could be delayed waiting for the work to
complete, but that's a very, very small chance, and likely a very small delay.
kvm_arch_async_page_present_queued() unconditionaly makes a new request, i.e. will
effectively delay entering the guest, so the remaining work is really just:
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
__kvm_vcpu_wake_up(vcpu);
mmput(mm);
Since mmput() can't drop the last reference to the page tables if the vCPU is
still alive.
I think I'll spin off the async #PF fix to a separate series. There's are other
tangetially related cleanups that can be done, e.g. there's no reason to pin the
page tables while work is queued, async_pf_execute() can do mmget_not_zero() and
then bail if the process is dying. Then there's no need to do mmput() when
canceling work.
next prev parent reply other threads:[~2023-10-24 15:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 20:46 [PATCH 0/3] KVM: Fix KVM-owned file refcounting of KVM module(s) Sean Christopherson
2023-10-18 20:46 ` [PATCH 1/3] KVM: Set file_operations.owner appropriately for all such structures Sean Christopherson
2023-10-18 20:46 ` [PATCH 2/3] KVM: Always flush async #PF workqueue when vCPU is being destroyed Sean Christopherson
2023-10-23 18:24 ` David Matlack
2023-10-24 8:21 ` Xu Yilun
2023-10-24 15:49 ` Sean Christopherson [this message]
2023-10-25 4:25 ` Xu Yilun
2023-10-18 20:46 ` [PATCH 3/3] Revert "KVM: Prevent module exit until all VMs are freed" Sean Christopherson
2023-12-01 23:30 ` [PATCH 0/3] KVM: Fix KVM-owned file refcounting of KVM module(s) Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTfnhEocglG1AsO8@google.com \
--to=seanjc@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox