[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Teddy Astie" <teddy.astie@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: "Tu Dinh" <ngoc-tu.dinh@xxxxxxxxxx>
  • Date: Thu, 26 Mar 2026 10:35:53 +0000
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=mte1 header.d=mandrillapp.com header.i="@mandrillapp.com" header.h="From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding"; dkim=pass header.s=mte1 header.d=vates.tech header.i="ngoc-tu.dinh@xxxxxxxxxx" header.h="From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding"
  • Cc: "Jan Beulich" <jbeulich@xxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, "Roger Pau Monné" <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 26 Mar 2026 10:35:58 +0000
  • Feedback-id: 30504962:30504962.20260326:md
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.