[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230607020743.GA53474@dev-dsk-luizcap-1d-37beaf15.us-east-1.amazon.com>
Date: Wed, 7 Jun 2023 02:08:11 +0000
From: Luiz Capitulino <luizcap@...zon.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Paolo Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Li RongQing <lirongqing@...du.com>,
Yong He <zhuangel570@...il.com>,
Robert Hoo <robert.hoo.linux@...il.com>,
Kai Huang <kai.huang@...el.com>
Subject: Re: [PATCH] KVM: x86/mmu: Add "never" option to allow sticky
disabling of nx_huge_pages
On Tue, Jun 06, 2023 at 03:03:38PM -0700, Sean Christopherson wrote:
>
>
>
> On Tue, Jun 06, 2023, Luiz Capitulino wrote:
> > On Thu, Jun 01, 2023 at 05:58:59PM -0700, Sean Christopherson wrote:
> > However, why don't we make nx_huge_pages=never the default behavior if the
> > CPU is not vulnerable?
>
> Mainly because the mitigation has been around for 3.5 years, and there's a non-zero
> chance that making "never" the default could cause hiccups for unsuspecting users.
> If this were brand new code, I would definitely opt for "never" as the default.
OK.
> > If there are concerns about not being able to restart the worker thread, then
> > maybe we could make this a .config option?
>
> Eh, a Kconfig is unnecessarily complex, and wouldn't really change anything, e.g.
> for users in the know, it's just as easy to force a module param as it is to force
> a Kconfig, and to gain any benefit from the param being !never by default, the
> Kconfig would also have to be off by default.
I agree it adds some complexity. The benefit is to allow shipping a kernel with
a good default where KVM users with non-vulnerable CPUs get low latency out
of the box (vs. having to figure out if they are vulnerable or not and changing
a run-time configuration).
But the idea would be to set "never" by default as long as the CPU is not vulnerable.
> If "everyone" wants never to be the default, and Paolo doesn't object, I'd rather
> just tack on a patch to make that happen, and cross my fingers there's no fallout :-)
This would work too :)
Powered by blists - more mailing lists