[RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[Teddy Astie]

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.tech

Re: [RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[Tu Dinh]

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.

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

Re: [RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[Jan Beulich]

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

Re: [RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[Teddy Astie]

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

Re: [RFC PATCH] x86/intel: Add recent CPU models model-specific LBRs

[Jan Beulich]

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