All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Keith Busch <kbusch@kernel.org>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	 michael.christie@oracle.com, Tejun Heo <tj@kernel.org>,
	 Luca Boccassi <bluca@debian.org>
Subject: Re: [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task
Date: Tue, 14 Jan 2025 19:06:20 -0800	[thread overview]
Message-ID: <Z4cmLAu4kdb3cCKo@google.com> (raw)
In-Reply-To: <0862979d-cb85-44a8-904b-7318a5be0460@redhat.com>

On Tue, Jan 14, 2025, Paolo Bonzini wrote:
> On 1/13/25 16:35, Keith Busch wrote:
> > > Ok, I found the code and it doesn't exec (e.g.
> > > https://github.com/google/crosvm/blob/b339d3d7/src/crosvm/sys/linux/jail_warden.rs#L122),
> > > so that's not an option. Well, if I understand correctly from a
> > > cursory look at the code, crosvm is creating a jailed child process
> > > early, and then spawns further jails through it; so it's just this
> > > first process that has to cheat.
> > > 
> > > One possibility on the KVM side is to delay creating the vhost_task
> > > until the first KVM_RUN. I don't like it but...
> > 
> > This option is actually kind of appealing in that we don't need to
> > change any application side to filter out kernel tasks, as well as not
> > having a new kernel dependency to even report these types of tasks as
> > kernel threads.
> > 
> > I gave it a quick try. I'm not very familiar with the code here, so not
> > sure if this is thread safe or not,

It's not.

> > but it did successfully get crosvm booting again.
> 
> That looks good to me too.  Would you like to send it with a commit message
> and SoB?

> > ---
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 2401606db2604..422b6b06de4fe 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -7415,6 +7415,8 @@ int kvm_mmu_post_init_vm(struct kvm *kvm)
> >   {
> >   	if (nx_hugepage_mitigation_hard_disabled)
> >   		return 0;
> > +	if (kvm->arch.nx_huge_page_recovery_thread)
> > +		return 0;

...

> >   	kvm->arch.nx_huge_page_last = get_jiffies_64();
> >   	kvm->arch.nx_huge_page_recovery_thread = vhost_task_create(
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index c79a8cc57ba42..263363c46626b 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -11463,6 +11463,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> >   	struct kvm_run *kvm_run = vcpu->run;
> >   	int r;
> > +	r = kvm_mmu_post_init_vm(vcpu->kvm);
> > +	if (r)
> > +		return r;

The only lock held at this point is vcpu->mutex, the obvious choices for guarding
the per-VM task creation are kvm->lock or kvm->mmu_lock, but we definitely don't
want to blindly take either lock in KVM_RUN.

  reply	other threads:[~2025-01-15  3:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 13:07 [PATCH] KVM: x86: switch hugepage recovery thread to vhost_task Paolo Bonzini
2024-11-08 16:53 ` Tejun Heo
2024-11-09  0:23   ` Luca Boccassi
2024-11-13 23:56 ` Sean Christopherson
2024-11-14 12:02   ` Paolo Bonzini
2024-11-14 15:38     ` Sean Christopherson
2025-01-22 14:16   ` Sasha Levin
2024-11-15 16:59 ` Michal Koutný
2024-11-18 12:42   ` Paolo Bonzini
2024-11-25  9:01     ` Michal Koutný
2024-11-25 11:22       ` Paolo Bonzini
2024-12-19 17:32 ` Keith Busch
2024-12-19 17:42   ` Paolo Bonzini
2024-12-19 18:08     ` Keith Busch
2024-12-19 20:30       ` Paolo Bonzini
2024-12-19 22:23         ` Keith Busch
2024-12-19 22:57           ` Paolo Bonzini
2024-12-19 23:31             ` Keith Busch
2025-01-13 15:35         ` Keith Busch
2025-01-14 18:10           ` Paolo Bonzini
2025-01-15  3:06             ` Sean Christopherson [this message]
2025-01-15 16:51               ` Keith Busch
2025-01-15 17:10                 ` Paolo Bonzini
2025-01-15 19:03                   ` Keith Busch
2025-01-22 11:38                     ` Alyssa Ross
2025-01-22 14:56                       ` Keith Busch
2025-01-22 22:32                         ` Alyssa Ross
2025-01-22 14:16                     ` Sasha Levin
2025-01-22 14:16           ` Sasha Levin
2025-01-22 14:16 ` Sasha Levin

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=Z4cmLAu4kdb3cCKo@google.com \
    --to=seanjc@google.com \
    --cc=bluca@debian.org \
    --cc=kbusch@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=tj@kernel.org \
    /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.