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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Might be an option, yes.

Jan