[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <128D2BA1-AFC6-4147-9BCD-7C148DFF7A33@nutanix.com>
Date: Mon, 20 Oct 2025 20:29:42 +0000
From: Jon Kohler <jon@...anix.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: Dave Hansen <dave.hansen@...el.com>,
Sean Christopherson
<seanjc@...gle.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 20, 2025, at 3:53 PM, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> On Mon, Oct 20, 2025 at 07:38:40PM +0000, Jon Kohler wrote:
>>
>>
>>> On Oct 20, 2025, at 3:26 PM, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com> wrote:
>>>
>>> !-------------------------------------------------------------------|
>>> CAUTION: External Email
>>>
>>> |-------------------------------------------------------------------!
>>>
>>> On Mon, Oct 20, 2025 at 09:21:41AM -0700, Dave Hansen wrote:
>>>> On 10/20/25 09:05, Jon Kohler wrote:
>>>>> Was running into some testing issues with my qemu change internally,
>>>>> but I’ll get that out this week once I clear them.
>>>>
>>>> BTW, if there are folks out there that are working on things like QEMU
>>>> and want more formal or regular notification from vendors that a FOO_NO
>>>> bit has been added, that can probably be arranged.
>>>>
>>>> The real issue here is that nobody cared enough to get QEMU to
>>>> comprehend ITS_NO right after the embargo was lifted, right?
>>>
>>> ITS_NO support was added to QEMU right after the embargo was lifted:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_8c1797e488b42650f62d816f25c58726eb522fad.1745946029.git.pawan.kumar.gupta-40linux.intel.com_&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=VbwUoxssQYa-v84la6cXovWYpxyF8bkkceV-vYCb49Uub4S7nrlIY9X_76fNKHh4&s=4EIqw5U1jEwif_3zPCXppj9ss0-Ogv1cFVUscBE7hxU&e=
>>
>> Pawan - I saw that, but I wasn’t able to get that to work, as the supported
>> feature checker will fail, and the VM will fail to start.
>>
>> Specifically, kvm_arch_get_supported_msr_feature() will not show it as a
>> “supported” bit, and kick it back, and you’ll get an error like so when setting
>> -cpu … “,its-no=yes"
>>
>> qemu-kvm: warning: host doesn't support requested feature: MSR(10AH).its-no [bit 62]
>>
>> That’s because qemu queries KVM side, which is checking against supported
>> hardware bits. Since this doesn’t come from hardware, it goes boom.
>
> So this check isn't working?
>
> kvm_get_arch_capabilities()
> {
> ...
> if (!boot_cpu_has_bug(X86_BUG_ITS))
> data |= ARCH_CAP_ITS_NO;
Ah! Ok, let me triple check the system under test and get back to you
Powered by blists - more mailing lists