All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Luiz Capitulino <luizcap@amazon.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Li RongQing <lirongqing@baidu.com>,
	Yong He <zhuangel570@gmail.com>,
	Robert Hoo <robert.hoo.linux@gmail.com>,
	Kai Huang <kai.huang@intel.com>
Subject: Re: [PATCH] KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages
Date: Wed, 14 Jun 2023 12:07:57 -0700	[thread overview]
Message-ID: <ZIoQDbte/uAiit9N@google.com> (raw)
In-Reply-To: <abf509a2-ebfd-7b5f-4f7a-fdd4ef60c1de@amazon.com>

On Wed, Jun 14, 2023, Luiz Capitulino wrote:
> 
> 
> On 2023-06-13 19:21, Sean Christopherson wrote:
> 
> > 
> > 
> > 
> > On Thu, 01 Jun 2023 17:58:59 -0700, Sean Christopherson wrote:
> > > Add a "never" option to the nx_huge_pages module param to allow userspace
> > > to do a one-way hard disabling of the mitigation, and don't create the
> > > per-VM recovery threads when the mitigation is hard disabled.  Letting
> > > userspace pinky swear that userspace doesn't want to enable NX mitigation
> > > (without reloading KVM) allows certain use cases to avoid the latency
> > > problems associated with spawning a kthread for each VM.
> > > 
> > > [...]
> > 
> > Applied to kvm-x86 mmu.  I kept the default as "auto" for now, as that can go on
> > top and I don't want to introduce that change this late in the cycle.  If no one
> > beats me to the punch (hint, hint ;-) ), I'll post a patch to make "never" the
> > default for unaffected hosts so that we can discuss/consider that change for 6.6.
> 
> Thanks Sean, I agree with the plan. I could give a try on the patch if you'd like.

Yes please, thanks!

  reply	other threads:[~2023-06-14 19:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02  0:58 [PATCH] KVM: x86/mmu: Add "never" option to allow sticky disabling of nx_huge_pages Sean Christopherson
2023-06-02  6:06 ` Robert Hoo
2023-06-02 15:09   ` Sean Christopherson
2023-06-03  0:54     ` Robert Hoo
2023-06-06  9:47     ` Huang, Kai
2023-06-05  4:26 ` Li,Rongqing
2023-06-06 20:26 ` Luiz Capitulino
2023-06-06 22:03   ` Sean Christopherson
2023-06-07  2:08     ` Luiz Capitulino
2023-06-13 23:21 ` Sean Christopherson
2023-06-14 13:20   ` Luiz Capitulino
2023-06-14 19:07     ` Sean Christopherson [this message]
2023-07-11 16:12       ` Like Xu
2023-07-12 23:47         ` 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=ZIoQDbte/uAiit9N@google.com \
    --to=seanjc@google.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=luizcap@amazon.com \
    --cc=pbonzini@redhat.com \
    --cc=robert.hoo.linux@gmail.com \
    --cc=zhuangel570@gmail.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.