From: Sean Christopherson <seanjc@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
David Matlack <dmatlack@google.com>,
Xu Yilun <yilun.xu@linux.intel.com>
Subject: Re: [PATCH 3/4] KVM: Get reference to VM's address space in the async #PF worker
Date: Fri, 26 Jan 2024 08:39:20 -0800 [thread overview]
Message-ID: <ZbPgOLVk4armOGDi@google.com> (raw)
In-Reply-To: <87sf2k83qb.fsf@redhat.com>
On Fri, Jan 26, 2024, Vitaly Kuznetsov wrote:
> Sean Christopherson <seanjc@google.com> writes:
>
> > Get a reference to the target VM's address space in async_pf_execute()
> > instead of gifting a reference from kvm_setup_async_pf(). Keeping the
> > address space alive just to service an async #PF is counter-productive,
> > i.e. if the process is exiting and all vCPUs are dead, then NOT doing
> > get_user_pages_remote() and freeing the address space asap is
> > desirable.
>
> It took me a while to realize why all vCPU fds are managed by the same
> mm which did KVM_CREATE_VM as (AFAIU) fds can be passed around. Turns
> out, we explicitly forbid this in kvm_vcpu_ioctl():
>
> if (vcpu->kvm->mm != current->mm || vcpu->kvm->vm_dead)
> return -EIO;
>
> so this indeed means that grabbing current->mm in kvm_setup_async_pf()
> can be avoided. I'm not sure whether it's just me or a "all vCPUs are
> quired to be managed by the same mm" comment somewhere would be helpful.
It's definitely not just you. Documentation/virt/kvm/* could use thorough
documentation of what all in KVM relies on vCPUs, and all meaningful ioctls(),
to be executed in the same mm_struct (address space). Because that requirement
is pervasive throughout KVM. E.g. sharing KVM page tables across vCPUs is safe
iff all vCPUs are in the same address space, otherwise the hva=>pfn translations
through the memslot would diverge, mmu_notifiers would be all kinds of broken, etc.
next prev parent reply other threads:[~2024-01-26 16:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 1:15 [PATCH 0/4] KVM: Async #PF fixes and cleanups Sean Christopherson
2024-01-10 1:15 ` [PATCH 1/4] KVM: Always flush async #PF workqueue when vCPU is being destroyed Sean Christopherson
2024-01-20 12:40 ` Xu Yilun
2024-01-24 19:04 ` Sean Christopherson
2024-01-26 7:36 ` Xu Yilun
2024-02-06 19:06 ` Sean Christopherson
2024-01-26 16:51 ` Vitaly Kuznetsov
2024-01-26 17:19 ` Sean Christopherson
2024-01-29 9:02 ` Vitaly Kuznetsov
2024-02-19 13:59 ` Xu Yilun
2024-02-19 15:51 ` Sean Christopherson
2024-02-20 3:02 ` Xu Yilun
2024-01-10 1:15 ` [PATCH 2/4] KVM: Put mm immediately after async #PF worker completes remote gup() Sean Christopherson
2024-01-20 15:24 ` Xu Yilun
2024-01-26 16:23 ` Vitaly Kuznetsov
2024-01-10 1:15 ` [PATCH 3/4] KVM: Get reference to VM's address space in the async #PF worker Sean Christopherson
2024-01-20 15:16 ` Xu Yilun
2024-01-24 18:52 ` Sean Christopherson
2024-01-26 8:06 ` Xu Yilun
2024-01-26 16:21 ` Vitaly Kuznetsov
2024-01-26 16:39 ` Sean Christopherson [this message]
2024-01-10 1:15 ` [PATCH 4/4] KVM: Nullify async #PF worker's "apf" pointer as soon as it might be freed Sean Christopherson
2024-01-20 15:24 ` Xu Yilun
2024-01-26 16:30 ` Vitaly Kuznetsov
2024-02-06 21:36 ` [PATCH 0/4] KVM: Async #PF fixes and cleanups 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=ZbPgOLVk4armOGDi@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=vkuznets@redhat.com \
--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