Add all CPU models that supports these MSR as they are defined in February 2026 SDM.
It uses the same list that span from Skylake to latest CPU models as a part of
MSRs in the 6th—13th generation Intel® Core™ processors,
1st—5th generation Intel® Xeon® Scalable processor families,
Intel® Core™ Ultra 7 processors, 8th generation Intel® Core™ i3
processors, Intel® Xeon® E processors, Intel® Xeon® 6 P-Core
processors, Intel® Xeon® 6 E-Core processors, and Intel® Series 2
Core™ Ultra processors
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
Currently, none of these MSR are exposed on these CPUs, leading to BSOD [1]
in Windows when it is supposedly trying to debug some program.
I guess [2] is also caused by these missing MSRs.
[1] https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod
[2] https://lore.kernel.org/xen-devel/ced16fca-3b55-40a1-a7e2-ffadd9707394@vates.tech/
xen/arch/x86/hvm/vmx/vmx.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 82c55f49ae..98a25ce301 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -541,10 +541,26 @@ static const struct lbr_info *__init get_model_specific_lbr(void)
case 0x8c: case 0x8d:
/* Tremont */
case 0x86:
+ /* Saphire Rapids */
+ case 0x8f:
/* Kaby Lake */
case 0x8e: case 0x9e:
+ /* Alder Lake */
+ case 0x97: case 0x9a:
/* Comet Lake */
case 0xa5: case 0xa6:
+ /* Meteor Lake */
+ case 0xaa:
+ /* Granite Rapids */
+ case 0xad: case 0xae:
+ /* Sierra Forest */
+ case 0xaf:
+ /* Raptor Lake */
+ case 0xba: case 0xb7: case 0xbf:
+ /* Lunar Lake */
+ case 0xbd:
+ /* Emerald Rapids */
+ case 0xcf:
return sk_lbr;
/* Atom */
case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36:
--
2.52.0
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.techOn 26/03/2026 11:21, Teddy Astie wrote: > Add all CPU models that supports these MSR as they are defined in February 2026 SDM. > It uses the same list that span from Skylake to latest CPU models as a part of > > MSRs in the 6th—13th generation Intel® Core™ processors, > 1st—5th generation Intel® Xeon® Scalable processor families, > Intel® Core™ Ultra 7 processors, 8th generation Intel® Core™ i3 > processors, Intel® Xeon® E processors, Intel® Xeon® 6 P-Core > processors, Intel® Xeon® 6 E-Core processors, and Intel® Series 2 > Core™ Ultra processors > > Signed-off-by: Teddy Astie <teddy.astie@vates.tech> > --- > Currently, none of these MSR are exposed on these CPUs, leading to BSOD [1] > in Windows when it is supposedly trying to debug some program. > > I guess [2] is also caused by these missing MSRs. > > [1] https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod > [2] https://lore.kernel.org/xen-devel/ced16fca-3b55-40a1-a7e2-ffadd9707394@vates.tech/ > > xen/arch/x86/hvm/vmx/vmx.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > I don't think CPU models with architectural LBRs should be stuffed together with the model-specific ones instead of having their own case. With that said, short of fully implementing arch LBR, it might make sense to at least stub out the LER MSRs to allow Windows to read them without crashing, as certain versions of Windows use LER MSR indexes without checking the arch LBR CPUID bit. > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 82c55f49ae..98a25ce301 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -541,10 +541,26 @@ static const struct lbr_info *__init get_model_specific_lbr(void) > case 0x8c: case 0x8d: > /* Tremont */ > case 0x86: > + /* Saphire Rapids */ > + case 0x8f: > /* Kaby Lake */ > case 0x8e: case 0x9e: > + /* Alder Lake */ > + case 0x97: case 0x9a: > /* Comet Lake */ > case 0xa5: case 0xa6: > + /* Meteor Lake */ > + case 0xaa: > + /* Granite Rapids */ > + case 0xad: case 0xae: > + /* Sierra Forest */ > + case 0xaf: > + /* Raptor Lake */ > + case 0xba: case 0xb7: case 0xbf: > + /* Lunar Lake */ > + case 0xbd: > + /* Emerald Rapids */ > + case 0xcf: > return sk_lbr; > /* Atom */ > case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36: -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 26.03.2026 11:35, Tu Dinh wrote: > On 26/03/2026 11:21, Teddy Astie wrote: >> Add all CPU models that supports these MSR as they are defined in February 2026 SDM. >> It uses the same list that span from Skylake to latest CPU models as a part of >> >> MSRs in the 6th—13th generation Intel® Core™ processors, >> 1st—5th generation Intel® Xeon® Scalable processor families, >> Intel® Core™ Ultra 7 processors, 8th generation Intel® Core™ i3 >> processors, Intel® Xeon® E processors, Intel® Xeon® 6 P-Core >> processors, Intel® Xeon® 6 E-Core processors, and Intel® Series 2 >> Core™ Ultra processors >> >> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >> --- >> Currently, none of these MSR are exposed on these CPUs, leading to BSOD [1] >> in Windows when it is supposedly trying to debug some program. >> >> I guess [2] is also caused by these missing MSRs. >> >> [1] https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod >> [2] https://lore.kernel.org/xen-devel/ced16fca-3b55-40a1-a7e2-ffadd9707394@vates.tech/ >> >> xen/arch/x86/hvm/vmx/vmx.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> > > I don't think CPU models with architectural LBRs should be stuffed > together with the model-specific ones instead of having their own case. I agree. We want to at least determine (or even enforce) how many LBRs are accessible. After all we can't be sure the DEPTH field hasn't been altered before we gained control. Beyond that, because arch-LBR enabling is a significant effort, I guess using the existing machinery for the time being might be okay. > With that said, short of fully implementing arch LBR, it might make > sense to at least stub out the LER MSRs to allow Windows to read them > without crashing, as certain versions of Windows use LER MSR indexes > without checking the arch LBR CPUID bit. This would be too Windows-centric for my taste. Jan
Le 26/03/2026 à 12:05, Jan Beulich a écrit :
> On 26.03.2026 11:35, Tu Dinh wrote:
>> On 26/03/2026 11:21, Teddy Astie wrote:
>>> Add all CPU models that supports these MSR as they are defined in February 2026 SDM.
>>> It uses the same list that span from Skylake to latest CPU models as a part of
>>>
>>> MSRs in the 6th—13th generation Intel® Core™ processors,
>>> 1st—5th generation Intel® Xeon® Scalable processor families,
>>> Intel® Core™ Ultra 7 processors, 8th generation Intel® Core™ i3
>>> processors, Intel® Xeon® E processors, Intel® Xeon® 6 P-Core
>>> processors, Intel® Xeon® 6 E-Core processors, and Intel® Series 2
>>> Core™ Ultra processors
>>>
>>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
>>> ---
>>> Currently, none of these MSR are exposed on these CPUs, leading to BSOD [1]
>>> in Windows when it is supposedly trying to debug some program.
>>>
>>> I guess [2] is also caused by these missing MSRs.
>>>
>>> [1] https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod
>>> [2] https://lore.kernel.org/xen-devel/ced16fca-3b55-40a1-a7e2-ffadd9707394@vates.tech/
>>>
>>> xen/arch/x86/hvm/vmx/vmx.c | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>
>> I don't think CPU models with architectural LBRs should be stuffed
>> together with the model-specific ones instead of having their own case.
>
> I agree. We want to at least determine (or even enforce) how many LBRs
> are accessible. After all we can't be sure the DEPTH field hasn't been
> altered before we gained control.
>
> Beyond that, because arch-LBR enabling is a significant effort, I guess
> using the existing machinery for the time being might be okay.
>
While Architectural LBR support could be useful on its own, I don't
think it would be enough.
If the guest is started without architectural LBR, the guest could
default into using model-specific ones (basing eventually on
Family-Model). That can happen if we migrate a guest from a Skylake-era
CPU to a Granite Rapids, yet we still need the guest to keep access to
model-specific ones, especially if they are stable across these CPU
generations.
>> With that said, short of fully implementing arch LBR, it might make
>> sense to at least stub out the LER MSRs to allow Windows to read them
>> without crashing, as certain versions of Windows use LER MSR indexes
>> without checking the arch LBR CPUID bit.
>
> This would be too Windows-centric for my taste.
>
A few specific LBR MSR happens to be stable and are identical between
architectural and model-specific lists.
MSR_IA32_LASTBRANCHFROMIP 0x000001db
MSR_IA32_LASTBRANCHTOIP 0x000001dc
MSR_IA32_LASTINTFROMIP 0x000001dd
MSR_IA32_LASTINTTOIP 0x000001de
In Xen, we already consider them somewhat "architectural", for instance,
traps-setup.c:init_ler always uses MSR_IA32_LASTINTFROMIP unless you are
running on a Pentium 4.
Perhaps for these ones at least, we should always expose them (unless
you are a Pentium 4) ? It may be enough to prevent some guests from
crashing when trying to access it.
Currently, it is only exposed if the CPU family is in this known list.
> Jan
>
Teddy
--
Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
On 26.03.2026 13:54, Teddy Astie wrote: > Le 26/03/2026 à 12:05, Jan Beulich a écrit : >> On 26.03.2026 11:35, Tu Dinh wrote: >>> On 26/03/2026 11:21, Teddy Astie wrote: >>>> Add all CPU models that supports these MSR as they are defined in February 2026 SDM. >>>> It uses the same list that span from Skylake to latest CPU models as a part of >>>> >>>> MSRs in the 6th—13th generation Intel® Core™ processors, >>>> 1st—5th generation Intel® Xeon® Scalable processor families, >>>> Intel® Core™ Ultra 7 processors, 8th generation Intel® Core™ i3 >>>> processors, Intel® Xeon® E processors, Intel® Xeon® 6 P-Core >>>> processors, Intel® Xeon® 6 E-Core processors, and Intel® Series 2 >>>> Core™ Ultra processors >>>> >>>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech> >>>> --- >>>> Currently, none of these MSR are exposed on these CPUs, leading to BSOD [1] >>>> in Windows when it is supposedly trying to debug some program. >>>> >>>> I guess [2] is also caused by these missing MSRs. >>>> >>>> [1] https://xcp-ng.org/forum/topic/12008/application-on-vm-causing-bsod >>>> [2] https://lore.kernel.org/xen-devel/ced16fca-3b55-40a1-a7e2-ffadd9707394@vates.tech/ >>>> >>>> xen/arch/x86/hvm/vmx/vmx.c | 16 ++++++++++++++++ >>>> 1 file changed, 16 insertions(+) >>>> >>> >>> I don't think CPU models with architectural LBRs should be stuffed >>> together with the model-specific ones instead of having their own case. >> >> I agree. We want to at least determine (or even enforce) how many LBRs >> are accessible. After all we can't be sure the DEPTH field hasn't been >> altered before we gained control. >> >> Beyond that, because arch-LBR enabling is a significant effort, I guess >> using the existing machinery for the time being might be okay. >> > > While Architectural LBR support could be useful on its own, I don't > think it would be enough. > > If the guest is started without architectural LBR, the guest could > default into using model-specific ones (basing eventually on > Family-Model). That can happen if we migrate a guest from a Skylake-era > CPU to a Granite Rapids, yet we still need the guest to keep access to > model-specific ones, especially if they are stable across these CPU > generations. > >>> With that said, short of fully implementing arch LBR, it might make >>> sense to at least stub out the LER MSRs to allow Windows to read them >>> without crashing, as certain versions of Windows use LER MSR indexes >>> without checking the arch LBR CPUID bit. >> >> This would be too Windows-centric for my taste. >> > > A few specific LBR MSR happens to be stable and are identical between > architectural and model-specific lists. > > MSR_IA32_LASTBRANCHFROMIP 0x000001db > MSR_IA32_LASTBRANCHTOIP 0x000001dc > MSR_IA32_LASTINTFROMIP 0x000001dd > MSR_IA32_LASTINTTOIP 0x000001de > > In Xen, we already consider them somewhat "architectural", for instance, > traps-setup.c:init_ler always uses MSR_IA32_LASTINTFROMIP unless you are > running on a Pentium 4. > > Perhaps for these ones at least, we should always expose them (unless > you are a Pentium 4) ? It may be enough to prevent some guests from > crashing when trying to access it. Might be an option, yes. Jan
© 2016 - 2026 Red Hat, Inc.