All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86/mmu: Ensure NX huge page recovery thread is alive before waking
Date: Mon, 27 Jan 2025 09:19:01 -0800	[thread overview]
Message-ID: <Z5fABRZuUz6o2cyF@google.com> (raw)
In-Reply-To: <Z5e8umkPeRri0Z_p@kbusch-mbp>

On Mon, Jan 27, 2025, Keith Busch wrote:
> On Mon, Jan 27, 2025 at 08:48:03AM -0800, Sean Christopherson wrote:
> > If vhost_task_create() fails, then the call_once() will "succeed" and mark the
> > structure as ONCE_COMPLETED.  The first KVM_RUN will fail with -ENOMEM, but any
> > subsequent calls will succeed, including in-flight KVM_RUNs on other threads.
> 
> The criteria for returning -ENOMEM for any KVM_RUN is if we have a NULL
> nx_huge_page_recovery_thread vhost_task. So I think that part, at least,
> is fine.
> 
> The call_once is just needed to ensure that only the very first KVM_RUN
> even tries to create it. If the vhost_task_create fails, then all the
> KVM_RUN threads will see the NULL nx_huge_page_recovery_thread and
> return -ENOMEM.

Ah, duh, because the check is performed by the caller, outside of the "once"
protection.

> What you're suggesting here will allow a subsequent thread to attempt
> creating the vhost task if the first one failed. Maybe you do want to
> try again, but the current upstream code doesn't retry this, so I
> thought it best to keep that behavior.

No strong opinion.  In practice, it's a moot point because the odds of a VM being
able to make forward progress if task creation hits an OOM are basically nil.

I'll defer to Paolo on what he thinks is best for the call_once() API.

  reply	other threads:[~2025-01-27 17:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-24 23:46 [PATCH] KVM: x86/mmu: Ensure NX huge page recovery thread is alive before waking Sean Christopherson
2025-01-25  0:50 ` Sean Christopherson
2025-01-25  4:11 ` Keith Busch
2025-01-27 16:48   ` Sean Christopherson
2025-01-27 17:04     ` Keith Busch
2025-01-27 17:19       ` Sean Christopherson [this message]
2025-01-27 18:22     ` Keith Busch
2025-01-28 15:41       ` Paolo Bonzini
2025-01-28 15:44         ` Keith Busch
2025-02-04 16:28 ` Paolo Bonzini

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=Z5fABRZuUz6o2cyF@google.com \
    --to=seanjc@google.com \
    --cc=kbusch@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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.