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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

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@xxxxxxxxxx>
>>> ---
>>> 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@xxxxxxxxxx/
>>>
>>>    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