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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.