[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F7C33A1C-2E4C-4B32-989F-CB9303D8A6BB@nutanix.com>
Date: Tue, 21 Oct 2025 15:40:24 +0000
From: Jon Kohler <jon@...anix.com>
To: Dave Hansen <dave.hansen@...el.com>
CC: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Thomas Gleixner
<tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra
<peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Jonathan Corbet
<corbet@....net>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen
<dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "H. Peter
Anvin" <hpa@...or.com>,
Brian Gerst <brgerst@...il.com>,
Brendan Jackman
<jackmanb@...gle.com>,
"Ahmed S. Darwish" <darwi@...utronix.de>,
Alexandre
Chartre <alexandre.chartre@...cle.com>,
"linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/its: use Sapphire Rapids+ feature to opt out
> On Oct 21, 2025, at 11:21 AM, Dave Hansen <dave.hansen@...el.com> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> On 10/21/25 07:39, Jon Kohler wrote:
>> For BHI_CTRL, depending on what QEMU the VM was originally *started* on,
>> the guest may have access to Sapphire Rapids models, but BHI_CTRL may
>> not have existed in the QEMU source at that time, as those were introduced
>> into two different timeframes.
>
> I have two solutions for you here, and neither of them involves patching
> the kernel.
>
> First, I personally volunteer to travel to your customers' homes to
> provide in-person education with my "education stick" about why updating
> software is important.
>
> Second, if they continue to be education-resistant, I offer to
> personally travel to the datacenters where these VMs are running to
> inspect the racks where they run and brainstorm solutions. A warning,
> though: I am quite clumsy and I've been known to bump into power cables
> and circuit breakers.
>
I get the sentiment, we’ll just have to document it as a recommendation and
move on.
Anyhow, there is at least one more active issue here, to make this marginally
easier on the QEMU side, which is to update the model definitions to make
ITS_NO auto-magic, such that the higher level control plane’s job is easier.
I’ll get that done separately.
Thanks for the back-n-forth and spirited debate here.
Cheers,
Jon
Powered by blists - more mailing lists