.../admin-guide/hw-vuln/indirect-target-selection.rst | 5 +++-- arch/x86/kernel/cpu/common.c | 6 ++++-- 2 files changed, 7 insertions(+), 4 deletions(-)
A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those
bits to determine whether they might be migrated to ITS-affected
hardware. Rather than depending on a control that may be absent, detect
ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire
Rapids and newer processors.
Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on
Sapphire Rapids+ parts and provides a reliable indicator that the guest
won't be moved to ITS-affected hardware. This avoids false negatives
caused by VMMs that omit ITS_NO or BHI_CTL. For example, QEMU added
bhi-ctrl only in v9.2.0 [1], well after adding the Sapphire Rapids
model in v8.0.0 [2].
[1] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")
[2] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Fixes: 159013a7ca1 ("x86/its: Enumerate Indirect Target Selection (ITS) bug")
Signed-off-by: Jon Kohler <jon@nutanix.com>
---
.../admin-guide/hw-vuln/indirect-target-selection.rst | 5 +++--
arch/x86/kernel/cpu/common.c | 6 ++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
index d9ca64108d23..3cfe4b9f9bd0 100644
--- a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
+++ b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
@@ -98,8 +98,9 @@ Mitigation in guests
^^^^^^^^^^^^^^^^^^^^
All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
and Family/Model of the guest. This is because eIBRS feature could be hidden
-from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
-indicates that the guest is running on an unaffected host.
+from a guest. One exception to this is when a guest enumerates BHI_DIS_S or
+BUS_LOCK_DETECT, either of which indicates that the guest is running on an
+unaffected host and would not be migratable to an affected host.
To prevent guests from unnecessarily deploying the mitigation on unaffected
platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c7d3512914ca..3de4b51d8681 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1361,9 +1361,11 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
/*
* If a VMM did not expose ITS_NO, assume that a guest could
* be running on a vulnerable hardware or may migrate to such
- * hardware.
+ * hardware, except in the situation where the guest is presented
+ * with a feature that only exists in non-vulnerable hardware.
*/
- if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
+ boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
return true;
if (cpu_matches(cpu_vuln_blacklist, ITS))
--
2.43.0On Thu, Oct 16, 2025 at 06:12:49PM -0700, Jon Kohler wrote: > A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those > bits to determine whether they might be migrated to ITS-affected > hardware. Rather than depending on a control that may be absent, detect > ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire > Rapids and newer processors. BHI_CTRL is also exclusive to Sapphire Rapids and newer processors. Why wouldn't it be exposed to guests but BUS_LOCK_DETECT would be? Not exposing BHI_CTRL has another disadvantage that guests would deploy the BHB-clear sequence when they could have used cheaper hardware mitigation for BHI. > Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on > Sapphire Rapids+ parts and provides a reliable indicator that the guest > won't be moved to ITS-affected hardware. I am puzzled why BUS_LOCK_DETECT is more reliable than BHI_CTRL?
> On Oct 20, 2025, at 3:44 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> On Thu, Oct 16, 2025 at 06:12:49PM -0700, Jon Kohler wrote:
>> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those
>> bits to determine whether they might be migrated to ITS-affected
>> hardware. Rather than depending on a control that may be absent, detect
>> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire
>> Rapids and newer processors.
>
> BHI_CTRL is also exclusive to Sapphire Rapids and newer processors. Why
> wouldn't it be exposed to guests but BUS_LOCK_DETECT would be?
>
> Not exposing BHI_CTRL has another disadvantage that guests would deploy the
> BHB-clear sequence when they could have used cheaper hardware mitigation
> for BHI.
Yes, I know, but given that BHI_CTRL comes via a spec_ctrl value change, it
has a negative effect at any guests live migrated in that never A) updated their
guest kernel to know about the new speculation controls and/or B) have updated
but have not yet soft rebooted and/or C) have updated, have soft rebooted, but
the BHI_CTRL isn’t actually available because the system hasn’t cold-booted
the VM(s) (see comments below).
In any of those three situations, subsequent guest/host transitions become
penalized. Now, from a security perspective, thats irrelevant because one
could say that if you really want to be secure, you have to do the work to make
sure all these cold boots are done, but that is far easier said than done in general
enterprise virtualization workloads.
Meaning, *if* a host opts into enabling BHI at all, they will penalize any guest
workload that hasn’t done the work to do the proper enablement cover to cover.
Less of a problem for hyperscaler who could control what launch/where, much
much harder for non-hyperscalers who might live migrate in extremely long tailed
workloads that feel like a federal project just to get a guest reboot, not to mention
a guest cold boot.
>
>> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on
>> Sapphire Rapids+ parts and provides a reliable indicator that the guest
>> won't be moved to ITS-affected hardware.
>
> I am puzzled why BUS_LOCK_DETECT is more reliable than BHI_CTRL?
Because BUS_LOCK_DETECT (or any other feature from commit [1]) was
available day 1 of the SPR QEMU model, whereas BHI_CTRL wasn’t added
until commit [2]. That means any VMM that added SPR support “day 1” has
the feature set from [1] at minimum, and it also means that if a guest VM was
*started* on that QEMU version, but never power cycled, it will never see
BHI_CTRL, even if it is available to be picked up in the latest model scheme.
I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do
it, but I suspect there are similar challenges around post-launch feature/bit
additions that require the VM to be completely cold-booted.
[1] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
[2] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")
On Mon, Oct 20, 2025 at 07:54:41PM +0000, Jon Kohler wrote: > > > > On Oct 20, 2025, at 3:44 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote: > > > > !-------------------------------------------------------------------| > > CAUTION: External Email > > > > |-------------------------------------------------------------------! > > > > On Thu, Oct 16, 2025 at 06:12:49PM -0700, Jon Kohler wrote: > >> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those > >> bits to determine whether they might be migrated to ITS-affected > >> hardware. Rather than depending on a control that may be absent, detect > >> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire > >> Rapids and newer processors. > > > > BHI_CTRL is also exclusive to Sapphire Rapids and newer processors. Why > > wouldn't it be exposed to guests but BUS_LOCK_DETECT would be? > > > > Not exposing BHI_CTRL has another disadvantage that guests would deploy the > > BHB-clear sequence when they could have used cheaper hardware mitigation > > for BHI. > > Yes, I know, but given that BHI_CTRL comes via a spec_ctrl value change, it > has a negative effect at any guests live migrated in that never A) updated their > guest kernel to know about the new speculation controls and/or B) have updated > but have not yet soft rebooted and/or Since ITS is newer than BHI_CTRL, deploying ITS mitigation unnecessarily shouldn't be a problem for A) and B), right? > C) have updated, have soft rebooted, but the BHI_CTRL isn’t actually > available because the system hasn’t cold-booted the VM(s) (see comments > below). This looks to be the main problem scenario. > In any of those three situations, subsequent guest/host transitions become > penalized. Now, from a security perspective, thats irrelevant because one > could say that if you really want to be secure, you have to do the work to make > sure all these cold boots are done, but that is far easier said than done in general > enterprise virtualization workloads. > > Meaning, *if* a host opts into enabling BHI at all, they will penalize any guest > workload that hasn’t done the work to do the proper enablement cover to cover. > Less of a problem for hyperscaler who could control what launch/where, much > much harder for non-hyperscalers who might live migrate in extremely long tailed > workloads that feel like a federal project just to get a guest reboot, not to mention > a guest cold boot. That seems orthogonal to the problem at hand, but I feel the pain. IIUC, you are referring to the wrmsr(SPEC_CTRL) at guest entry/exit because that have different MSR values. Host with BHI_DIS_S=1 and guest without it? Do you think adding support for virtual-SPEC_CTRL in QEMU would help here? > >> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on > >> Sapphire Rapids+ parts and provides a reliable indicator that the guest > >> won't be moved to ITS-affected hardware. > > > > I am puzzled why BUS_LOCK_DETECT is more reliable than BHI_CTRL? > > Because BUS_LOCK_DETECT (or any other feature from commit [1]) was > available day 1 of the SPR QEMU model, whereas BHI_CTRL wasn’t added > until commit [2]. That means any VMM that added SPR support “day 1” has > the feature set from [1] at minimum, and it also means that if a guest VM was > *started* on that QEMU version, but never power cycled, it will never see > BHI_CTRL, even if it is available to be picked up in the latest model scheme. > > I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do > it, but I suspect there are similar challenges around post-launch feature/bit > additions that require the VM to be completely cold-booted. Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it be better to replace BHI_CTRL with BUS_LOCK_DETECT. --- diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 1755f91a5643..e8fc4a4055bf 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1355,8 +1355,8 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr) if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) return false; - /* None of the affected CPUs have BHI_CTRL */ - if (boot_cpu_has(X86_FEATURE_BHI_CTRL)) + /* None of the affected CPUs have BUS_LOCK_DETECT */ + if (boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT)) return false; /*
On 10/20/25 13:40, Pawan Gupta wrote: >> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do >> it, but I suspect there are similar challenges around post-launch feature/bit >> additions that require the VM to be completely cold-booted. > Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it > be better to replace BHI_CTRL with BUS_LOCK_DETECT. Folks, I just think this kind of random feature spaghetti voodoo is a bad idea. Suppose X86_FEATURE_BUS_LOCK_DETECT is in silicon on an affected part but normally fused off. But a big customer shows up with a big checkbook and Intel releases microcode to enumerate X86_FEATURE_BUS_LOCK_DETECT on an affected part. What then? Your only choice is to convince Intel to make architectural the idea that X86_FEATURE_BUS_LOCK_DETECT is never enumerated on an affected part. Because even if we go forward with that patch we've *DONE* that in Linux: we've made it de facto architecture and Intel can never change it. Can someone try to boil down the problem statement for me again, please? VMs are slow because of mitigations for issues to which they are not vulnerable when running old kernels on old hypervisors. Is that it?
On Mon, Oct 20, 2025 at 03:09:41PM -0700, Dave Hansen wrote: > On 10/20/25 13:40, Pawan Gupta wrote: > >> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do > >> it, but I suspect there are similar challenges around post-launch feature/bit > >> additions that require the VM to be completely cold-booted. > > Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it > > be better to replace BHI_CTRL with BUS_LOCK_DETECT. > > Folks, I just think this kind of random feature spaghetti voodoo is a > bad idea. Suppose X86_FEATURE_BUS_LOCK_DETECT is in silicon on an > affected part but normally fused off. But a big customer shows up with a > big checkbook and Intel releases microcode to enumerate > X86_FEATURE_BUS_LOCK_DETECT on an affected part. Hmm, right. > What then? > > Your only choice is to convince Intel to make architectural the idea > that X86_FEATURE_BUS_LOCK_DETECT is never enumerated on an affected part. > > Because even if we go forward with that patch we've *DONE* that in > Linux: we've made it de facto architecture and Intel can never change it. Using BHI_CTRL here was in agreement with CPU architects. Even though its a heuristic, it is very unlikely to be broken by a microcode update. I can't say for sure about BUS_LOCK_DETECT. > Can someone try to boil down the problem statement for me again, please? > > VMs are slow because of mitigations for issues to which they are > not vulnerable when running old kernels on old hypervisors. From what I understand: Unless a VM is cold-booted, it cannot see the new features/immunity bits exposed by the hypervisor. In this particular case, a guest gets the updated kernel with ITS mitigation, but can't see the immunity bit unless it is cold-booted. The other part of the problem is when host kernel/hypervisor is not updated. In this case immunity bit is not exposed to the guest at all. My 2 cents: All of this makes me feel the instead of exposing the immunity bit, a guest should be told about the bug presence. That way security minded users who update regularly get the bug enumerations, and hence the mitigations. OTOH, performance focused users who don't update/cold-boot often don't get unnecessarily slowed down.
> On Oct 20, 2025, at 6:41 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > On Mon, Oct 20, 2025 at 03:09:41PM -0700, Dave Hansen wrote: >> On 10/20/25 13:40, Pawan Gupta wrote: >>>> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do >>>> it, but I suspect there are similar challenges around post-launch feature/bit >>>> additions that require the VM to be completely cold-booted. First thing, I want to apologize for the confusion yesterday when talking about the QEMU enablement, I’m sorry I mis-represented that. Wasn’t intentional, that was me getting my wires crossed. The baseline enablement its-no is there if you’ve got both the QEMU and kernel side together, its-no=yes should work. Not that isn’t exposed natively on any CPU models from the looks of it. I can propose a patch on the qemu side for that. >>> Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it >>> be better to replace BHI_CTRL with BUS_LOCK_DETECT. >> >> Folks, I just think this kind of random feature spaghetti voodoo is a >> bad idea. Suppose X86_FEATURE_BUS_LOCK_DETECT is in silicon on an >> affected part but normally fused off. But a big customer shows up with a >> big checkbook and Intel releases microcode to enumerate >> X86_FEATURE_BUS_LOCK_DETECT on an affected part. > > Hmm, right. > >> What then? >> >> Your only choice is to convince Intel to make architectural the idea >> that X86_FEATURE_BUS_LOCK_DETECT is never enumerated on an affected part. >> >> Because even if we go forward with that patch we've *DONE* that in >> Linux: we've made it de facto architecture and Intel can never change it. > > Using BHI_CTRL here was in agreement with CPU architects. Even though its a > heuristic, it is very unlikely to be broken by a microcode update. > > I can't say for sure about BUS_LOCK_DETECT. > >> Can someone try to boil down the problem statement for me again, please? >> >> VMs are slow because of mitigations for issues to which they are >> not vulnerable when running old kernels on old hypervisors. The problem statement is that, ITS is on by default, on non-impacted hardware, and at least for the QEMU ecosystem, the feature chosen (BHI_CTRL) was not exposed at the same time the SPR model was introduced, so guests on platforms that don’t have BHI_CTRL or ITS_NO for any reason will be impacted for performance, mitigating against an issue that they don’t actually have. So to simplify it down: A guest VM that updates to a ITS-enabled guest kernel sees performance impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or non-ITS_NO hypervisors, which is a very easy situation to get into, especially on QEMU with live migration-enabled pools. > > From what I understand: > > Unless a VM is cold-booted, it cannot see the new features/immunity bits > exposed by the hypervisor. In this particular case, a guest gets the > updated kernel with ITS mitigation, but can't see the immunity bit unless > it is cold-booted. > > The other part of the problem is when host kernel/hypervisor is not > updated. In this case immunity bit is not exposed to the guest at all. > > My 2 cents: All of this makes me feel the instead of exposing the immunity > bit, a guest should be told about the bug presence. That way security > minded users who update regularly get the bug enumerations, and hence the > mitigations. OTOH, performance focused users who don't update/cold-boot > often don't get unnecessarily slowed down.
On 10/21/25 06:40, Jon Kohler wrote: > So to simplify it down: > A guest VM that updates to a ITS-enabled guest kernel sees performance > impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or > non-ITS_NO hypervisors, which is a very easy situation to get into, especially > on QEMU with live migration-enabled pools. By non-$FEATURE, do you mean that they chose to not enumerate those features, or that they are completely ignorant of them?
> On Oct 21, 2025, at 10:01 AM, Dave Hansen <dave.hansen@intel.com> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > On 10/21/25 06:40, Jon Kohler wrote: >> So to simplify it down: >> A guest VM that updates to a ITS-enabled guest kernel sees performance >> impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or >> non-ITS_NO hypervisors, which is a very easy situation to get into, especially >> on QEMU with live migration-enabled pools. > > By non-$FEATURE, do you mean that they chose to not enumerate those > features, or that they are completely ignorant of them? Both cases are true for QEMU. For ITS_NO, it is an allowed feature, but its not part of a QEMU model by default, so the higher level control plane whatever that may be would need to specifically turn it on, its not automatic. 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.
On Tue, Oct 21, 2025 at 02:39:15PM +0000, Jon Kohler wrote: > > > > On Oct 21, 2025, at 10:01 AM, Dave Hansen <dave.hansen@intel.com> wrote: > > > > > > > > On 10/21/25 06:40, Jon Kohler wrote: > >> So to simplify it down: > >> A guest VM that updates to a ITS-enabled guest kernel sees performance > >> impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or > >> non-ITS_NO hypervisors, which is a very easy situation to get into, especially > >> on QEMU with live migration-enabled pools. > > > > By non-$FEATURE, do you mean that they chose to not enumerate those > > features, or that they are completely ignorant of them? > > Both cases are true for QEMU. > > For ITS_NO, it is an allowed feature, but its not part of a QEMU model by > default, so the higher level control plane whatever that may be would need to > specifically turn it on, its not automatic. > > 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. QEMU provides now a mechanism to update itself to a newer version. See https://blogs.oracle.com/linux/post/qemu-live-update That should solve your QEMU problem.
> On Oct 21, 2025, at 11:27 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > On Tue, Oct 21, 2025 at 02:39:15PM +0000, Jon Kohler wrote: >> >> >>> On Oct 21, 2025, at 10:01 AM, Dave Hansen <dave.hansen@intel.com> wrote: >>> >>>>> >>> On 10/21/25 06:40, Jon Kohler wrote: >>>> So to simplify it down: >>>> A guest VM that updates to a ITS-enabled guest kernel sees performance >>>> impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or >>>> non-ITS_NO hypervisors, which is a very easy situation to get into, especially >>>> on QEMU with live migration-enabled pools. >>> >>> By non-$FEATURE, do you mean that they chose to not enumerate those >>> features, or that they are completely ignorant of them? >> >> Both cases are true for QEMU. >> >> For ITS_NO, it is an allowed feature, but its not part of a QEMU model by >> default, so the higher level control plane whatever that may be would need to >> specifically turn it on, its not automatic. >> >> 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. > > QEMU provides now a mechanism to update itself to a newer version. See > > https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.oracle.com_linux_post_qemu-2Dlive-2Dupdate&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=UUSvpPViiTB6CJQtj3GREK4bQFz7MT9uNiAu5AL3O23d6I1yk4vheLDyR41ZcbRI&s=x19gwHU3HGXSlGkK0ppkawex3SIbs8xHj5hPtwNCFwc&e= > > That should solve your QEMU problem. Can this live update feature change CPU feature bits (e.g. add on -cpu ModelHere … new_flag=yes) during the update? Can it change CPU models during the live update (e.g. change -cpu Model-v1 to -cpu Model-v2)?
On Tue, Oct 21, 2025 at 03:35:28PM +0000, Jon Kohler wrote: > > > > On Oct 21, 2025, at 11:27 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > > > > > > > On Tue, Oct 21, 2025 at 02:39:15PM +0000, Jon Kohler wrote: > >> > >> > >>> On Oct 21, 2025, at 10:01 AM, Dave Hansen <dave.hansen@intel.com> wrote: > >>> > >>>>> > >>> On 10/21/25 06:40, Jon Kohler wrote: > >>>> So to simplify it down: > >>>> A guest VM that updates to a ITS-enabled guest kernel sees performance > >>>> impacts on non-vulnerable hardware, when running on non-BHI_CTRL and/or > >>>> non-ITS_NO hypervisors, which is a very easy situation to get into, especially > >>>> on QEMU with live migration-enabled pools. > >>> > >>> By non-$FEATURE, do you mean that they chose to not enumerate those > >>> features, or that they are completely ignorant of them? > >> > >> Both cases are true for QEMU. > >> > >> For ITS_NO, it is an allowed feature, but its not part of a QEMU model by > >> default, so the higher level control plane whatever that may be would need to > >> specifically turn it on, its not automatic. > >> > >> 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. > > > > QEMU provides now a mechanism to update itself to a newer version. See > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.oracle.com_linux_post_qemu-2Dlive-2Dupdate&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=UUSvpPViiTB6CJQtj3GREK4bQFz7MT9uNiAu5AL3O23d6I1yk4vheLDyR41ZcbRI&s=x19gwHU3HGXSlGkK0ppkawex3SIbs8xHj5hPtwNCFwc&e= > > > > That should solve your QEMU problem. > > Can this live update feature change CPU feature bits (e.g. add on > -cpu ModelHere … new_flag=yes) during the update? It is possible, but a pain in operation b/c you have to keep track of the newer parameters you are adding and if add some device in wrong order (wrong PCI BDF), well, things won't be nice. > > Can it change CPU models during the live update (e.g. change > -cpu Model-v1 to -cpu Model-v2)? Not exactly. But you can modify the built-in Model-v1 (in the newer version) to have the newer CPU flags and it will carry-over. Anyhow it is all in the latest version of QEMU.
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.
> On Oct 21, 2025, at 11:21 AM, Dave Hansen <dave.hansen@intel.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
> On Oct 20, 2025, at 4:40 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > On Mon, Oct 20, 2025 at 07:54:41PM +0000, Jon Kohler wrote: >> >> >>> On Oct 20, 2025, at 3:44 PM, Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote: >>> >>> !-------------------------------------------------------------------| >>> CAUTION: External Email >>> >>> |-------------------------------------------------------------------! >>> >>> On Thu, Oct 16, 2025 at 06:12:49PM -0700, Jon Kohler wrote: >>>> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those >>>> bits to determine whether they might be migrated to ITS-affected >>>> hardware. Rather than depending on a control that may be absent, detect >>>> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire >>>> Rapids and newer processors. >>> >>> BHI_CTRL is also exclusive to Sapphire Rapids and newer processors. Why >>> wouldn't it be exposed to guests but BUS_LOCK_DETECT would be? >>> >>> Not exposing BHI_CTRL has another disadvantage that guests would deploy the >>> BHB-clear sequence when they could have used cheaper hardware mitigation >>> for BHI. >> >> Yes, I know, but given that BHI_CTRL comes via a spec_ctrl value change, it >> has a negative effect at any guests live migrated in that never A) updated their >> guest kernel to know about the new speculation controls and/or B) have updated >> but have not yet soft rebooted and/or > > Since ITS is newer than BHI_CTRL, deploying ITS mitigation unnecessarily > shouldn't be a problem for A) and B), right? 100%, this is much easier in that regard because it is not touching SPEC_CTRL > >> C) have updated, have soft rebooted, but the BHI_CTRL isn’t actually >> available because the system hasn’t cold-booted the VM(s) (see comments >> below). > > This looks to be the main problem scenario. Yes >> In any of those three situations, subsequent guest/host transitions become >> penalized. Now, from a security perspective, thats irrelevant because one >> could say that if you really want to be secure, you have to do the work to make >> sure all these cold boots are done, but that is far easier said than done in general >> enterprise virtualization workloads. >> >> Meaning, *if* a host opts into enabling BHI at all, they will penalize any guest >> workload that hasn’t done the work to do the proper enablement cover to cover. >> Less of a problem for hyperscaler who could control what launch/where, much >> much harder for non-hyperscalers who might live migrate in extremely long tailed >> workloads that feel like a federal project just to get a guest reboot, not to mention >> a guest cold boot. > > That seems orthogonal to the problem at hand, but I feel the pain. IIUC, > you are referring to the wrmsr(SPEC_CTRL) at guest entry/exit because that > have different MSR values. Host with BHI_DIS_S=1 and guest without it? Do > you think adding support for virtual-SPEC_CTRL in QEMU would help here? > >>>> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on >>>> Sapphire Rapids+ parts and provides a reliable indicator that the guest >>>> won't be moved to ITS-affected hardware. >>> >>> I am puzzled why BUS_LOCK_DETECT is more reliable than BHI_CTRL? >> >> Because BUS_LOCK_DETECT (or any other feature from commit [1]) was >> available day 1 of the SPR QEMU model, whereas BHI_CTRL wasn’t added >> until commit [2]. That means any VMM that added SPR support “day 1” has >> the feature set from [1] at minimum, and it also means that if a guest VM was >> *started* on that QEMU version, but never power cycled, it will never see >> BHI_CTRL, even if it is available to be picked up in the latest model scheme. >> >> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do >> it, but I suspect there are similar challenges around post-launch feature/bit >> additions that require the VM to be completely cold-booted. > > Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it > be better to replace BHI_CTRL with BUS_LOCK_DETECT. > > --- > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 1755f91a5643..e8fc4a4055bf 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -1355,8 +1355,8 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr) > if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) > return false; > > - /* None of the affected CPUs have BHI_CTRL */ > - if (boot_cpu_has(X86_FEATURE_BHI_CTRL)) > + /* None of the affected CPUs have BUS_LOCK_DETECT */ > + if (boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT)) > return false; > > /* Ok, thank you for the back and forth. I’ll do some more poking around and see if I can double check this approach on other platforms, to see if I can smoke out any other oddball edge cases.
On Thu, Oct 16, 2025, Jon Kohler wrote:
> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those
> bits to determine whether they might be migrated to ITS-affected
> hardware. Rather than depending on a control that may be absent, detect
> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire
> Rapids and newer processors.
>
> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on
> Sapphire Rapids+ parts and provides a reliable indicator that the guest
> won't be moved to ITS-affected hardware. This avoids false negatives
> caused by VMMs that omit ITS_NO or BHI_CTL. For example, QEMU added
> bhi-ctrl only in v9.2.0 [1], well after adding the Sapphire Rapids
> model in v8.0.0 [2].
>
> [1] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")
> [2] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
>
> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Fixes: 159013a7ca1 ("x86/its: Enumerate Indirect Target Selection (ITS) bug")
> Signed-off-by: Jon Kohler <jon@nutanix.com>
> ---
> .../admin-guide/hw-vuln/indirect-target-selection.rst | 5 +++--
> arch/x86/kernel/cpu/common.c | 6 ++++--
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
> index d9ca64108d23..3cfe4b9f9bd0 100644
> --- a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
> +++ b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
> @@ -98,8 +98,9 @@ Mitigation in guests
> ^^^^^^^^^^^^^^^^^^^^
> All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
> and Family/Model of the guest. This is because eIBRS feature could be hidden
> -from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
> -indicates that the guest is running on an unaffected host.
> +from a guest. One exception to this is when a guest enumerates BHI_DIS_S or
> +BUS_LOCK_DETECT, either of which indicates that the guest is running on an
> +unaffected host and would not be migratable to an affected host.
>
> To prevent guests from unnecessarily deploying the mitigation on unaffected
> platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c7d3512914ca..3de4b51d8681 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1361,9 +1361,11 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
> /*
> * If a VMM did not expose ITS_NO, assume that a guest could
> * be running on a vulnerable hardware or may migrate to such
> - * hardware.
> + * hardware, except in the situation where the guest is presented
> + * with a feature that only exists in non-vulnerable hardware.
> */
> - if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
> + boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
Uh, don't you want something like this?
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c7d3512914ca..8c4bc9b5d8ed 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1364,7 +1364,7 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
* hardware.
*/
if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
- return true;
+ return !boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT);
if (cpu_matches(cpu_vuln_blacklist, ITS))
return true;
Functionality aside, this is quite heinous. I don't see why the answer isn't
"Fix the VMM to specify ITS_NO".
> On Oct 20, 2025, at 11:48 AM, Sean Christopherson <seanjc@google.com> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> On Thu, Oct 16, 2025, Jon Kohler wrote:
>> A VMM may not expose ITS_NO or BHI_CTL, so guests cannot rely on those
>> bits to determine whether they might be migrated to ITS-affected
>> hardware. Rather than depending on a control that may be absent, detect
>> ITS-unaffected hosts via a CPU feature that is exclusive to Sapphire
>> Rapids and newer processors.
>>
>> Use X86_FEATURE_BUS_LOCK_DETECT as the canary: it is present on
>> Sapphire Rapids+ parts and provides a reliable indicator that the guest
>> won't be moved to ITS-affected hardware. This avoids false negatives
>> caused by VMMs that omit ITS_NO or BHI_CTL. For example, QEMU added
>> bhi-ctrl only in v9.2.0 [1], well after adding the Sapphire Rapids
>> model in v8.0.0 [2].
>>
>> [1] 10eaf9c0fb7 ("target/i386: Add more features enumerated by CPUID.7.2.EDX")
>> [2] 7eb061b06e9 ("i386: Add new CPU model SapphireRapids")
>>
>> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>> Fixes: 159013a7ca1 ("x86/its: Enumerate Indirect Target Selection (ITS) bug")
>> Signed-off-by: Jon Kohler <jon@nutanix.com>
>> ---
>> .../admin-guide/hw-vuln/indirect-target-selection.rst | 5 +++--
>> arch/x86/kernel/cpu/common.c | 6 ++++--
>> 2 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> index d9ca64108d23..3cfe4b9f9bd0 100644
>> --- a/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> +++ b/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst
>> @@ -98,8 +98,9 @@ Mitigation in guests
>> ^^^^^^^^^^^^^^^^^^^^
>> All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration
>> and Family/Model of the guest. This is because eIBRS feature could be hidden
>> -from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which
>> -indicates that the guest is running on an unaffected host.
>> +from a guest. One exception to this is when a guest enumerates BHI_DIS_S or
>> +BUS_LOCK_DETECT, either of which indicates that the guest is running on an
>> +unaffected host and would not be migratable to an affected host.
>>
>> To prevent guests from unnecessarily deploying the mitigation on unaffected
>> platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index c7d3512914ca..3de4b51d8681 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -1361,9 +1361,11 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
>> /*
>> * If a VMM did not expose ITS_NO, assume that a guest could
>> * be running on a vulnerable hardware or may migrate to such
>> - * hardware.
>> + * hardware, except in the situation where the guest is presented
>> + * with a feature that only exists in non-vulnerable hardware.
>> */
>> - if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
>> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
>> + boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
>
> Uh, don't you want something like this?
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c7d3512914ca..8c4bc9b5d8ed 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1364,7 +1364,7 @@ static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
> * hardware.
> */
> if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> - return true;
> + return !boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT);
>
> if (cpu_matches(cpu_vuln_blacklist, ITS))
> return true;
>
> Functionality aside, this is quite heinous. I don't see why the answer isn't
> "Fix the VMM to specify ITS_NO".
Yes, I know it isn’t the prettiest person at the ball; however, the problem I was trying
to solve is guests being deployed on “old” VMMs, so we could stop the bleeding
from that side. The bummer of all of this is that the guest does have enough info
to solve this from the guest side without VMM involvement, but I’m not going to
litigate that as the ITS_NO approach is clear. Is what it is.
Was running into some testing issues with my qemu change internally, but I’ll
get that out this week once I clear them.
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?
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://lore.kernel.org/all/8c1797e488b42650f62d816f25c58726eb522fad.1745946029.git.pawan.kumar.gupta@linux.intel.com/
> On Oct 20, 2025, at 3:26 PM, Pawan Gupta <pawan.kumar.gupta@linux.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://lore.kernel.org/all/8c1797e488b42650f62d816f25c58726eb522fad.1745946029.git.pawan.kumar.gupta@linux.intel.com/ 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. I ran into something similar when dealing with the fb-clear emulation [1] that I added to qemu a week or so ago, and was thinking of something something similar-ish to get around just this same issue with its-no. I need to finish cooking that up and I’ll CC you on the QEMU side fix. [1] https://github.com/qemu/qemu/commit/00001a22d183ce96c110690987bf9dd6a8548552
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@linux.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://lore.kernel.org/all/8c1797e488b42650f62d816f25c58726eb522fad.1745946029.git.pawan.kumar.gupta@linux.intel.com/
>
> 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;
> On Oct 20, 2025, at 3:53 PM, Pawan Gupta <pawan.kumar.gupta@linux.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@linux.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
> On Oct 20, 2025, at 12:21 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > 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. That’d be nice! I’d be game for that. > The real issue here is that nobody cared enough to get QEMU to > comprehend ITS_NO right after the embargo was lifted, right? As a general statement, yes, but I’m not privy to any conversations that may have happened on non-googleable list(s), so it may have been discussed but never materialized … or maybe it was never discussed at all. Net-net though, you’re right, the drama is that the guests/distros have gotten hit with this, and on the virtualization platform side, we’ve effectively had zero time to prepare for this.
© 2016 - 2026 Red Hat, Inc.