From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 40EB410A62C0 for ; Thu, 26 Mar 2026 12:54:26 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1264015.1555761 (Exim 4.92) (envelope-from ) id 1w5kE3-0000ul-R9; Thu, 26 Mar 2026 12:54:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1264015.1555761; Thu, 26 Mar 2026 12:54:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w5kE3-0000ue-OR; Thu, 26 Mar 2026 12:54:15 +0000 Received: by outflank-mailman (input) for mailman id 1264015; Thu, 26 Mar 2026 12:54:14 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w5kE2-0000uU-9g for xen-devel@lists.xenproject.org; Thu, 26 Mar 2026 12:54:14 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1w5kE1-002wG4-KC for xen-devel@lists.xenproject.org; Thu, 26 Mar 2026 13:54:13 +0100 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 69c52c63-e002-0a2a0a5209dd-0a2a4507ae3e-44 for ; Thu, 26 Mar 2026 13:54:13 +0100 Received: from [198.2.180.47] (helo=mail180-47.suw31.mandrillapp.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.55.2) (envelope-from ) id 69c52c74-fd74-0a2a45070019-c602b42fb816-3 for ; Thu, 26 Mar 2026 13:54:13 +0100 Received: from pmta11.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail180-47.suw31.mandrillapp.com (Mailchimp) with ESMTP id 4fhNyD0ZwrzPm1FF5 for ; Thu, 26 Mar 2026 12:54:12 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 709d0f9814064cb5bcc5ee894dd456fe; Thu, 26 Mar 2026 12:54:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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="teddy.astie@vates.tech" header.h="From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1774529652; x=1774799652; bh=9ENfk9W5x+5JX/9DDcM93W1SN8UBRjYQUTb1bavyQnk=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=JKVwDe8zycmD2FWulg3GVOCHP/ArsmdmxDBDns9XZ5vdNon/KgnUcm0b9hbm1WyvJ Ws0WkKPXstY+NAMSKzBmWA2UL6lCHvYRfmqiQiBWGyOoF7h5FdZPc82kjtyAfr1cyO 5OjTx/lKxcY1PQF6ulUXmBtOkc51jEokJ+fCT5c/clMsY1o7wNq5DkOzcKvMB79udP 478L8SUoWB/pSVUhe+ToW/uVJi3Qm1VkZPOzEp5G654ytQkqJJr6ImuU3dmvJ2DiIO hNoMjGK4qbHYRBMO6AP5KCAFPzCkZpCdTzudwv22XSF6hnfTA2PHbNjWxjWAJ2Lpba LzvM30yWtaeew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1774529652; x=1774790152; i=teddy.astie@vates.tech; bh=9ENfk9W5x+5JX/9DDcM93W1SN8UBRjYQUTb1bavyQnk=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=sVKd9jlFQKN6P15JonMDflisg3sE2kgo5d9+aLo7C2on5QrRf7gax8Gfm9yBPD2fq iZQXmQGVYIQj1sZ20WDfSsf7KcmnrZbTh+IwhFGlAFY1iZBUvtaY5bpSFhbOIZ8Kec NU7F6Clr+aHgCL8jOAvJC/gWhXAi9k6oquPAiRBBnhdmhXYEkm6h0pPgupSPAGGZBA 5r5raYlBduEurwL47ULB7LsMzBNdC5rJKblLPHVgVtn6Q9zNkLMovplF5Qo8RtcR6Y Q/didwBp8UFEhZahLcbNNLfFpX70gsHrFmdBuUUDbCFdf87tdsz1Nod70m44f6LlTi FPf21tQyP7s0g== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20x86/intel:=20Add=20recent=20CPU=20models=20model-specific=20LBRs?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1774529650965 Message-Id: <7ccb48df-8255-4e01-9367-f9496fe2ee18@vates.tech> To: "Jan Beulich" , "Tu Dinh" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , xen-devel@lists.xenproject.org References: <888b0df36c6706de9d7ec1c5c4cc229297699670.1774519884.git.teddy.astie@vates.tech> <975b6883-646d-4db4-b931-b21c45d0507b@vates.tech> <1e95cf58-0e40-4cfe-8ac9-cd31d97f8330@suse.com> In-Reply-To: <1e95cf58-0e40-4cfe-8ac9-cd31d97f8330@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.709d0f9814064cb5bcc5ee894dd456fe?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260326:md Date: Thu, 26 Mar 2026 12:54:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1774529653-578A4303-18314A8C/0/0 X-purgate-type: clean X-purgate-size: 3549 Le 26/03/2026 =C3=A0 12:05, Jan Beulich a =C3=A9crit=C2=A0: > 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 Febru= ary 2026 SDM. >>> It uses the same list that span from Skylake to latest CPU models as a = part of >>> >>> MSRs in the 6th=E2=80=9413th generation Intel=C2=AE Core=E2=84=A2= processors, >>> 1st=E2=80=945th generation Intel=C2=AE Xeon=C2=AE Scalable proces= sor families, >>> Intel=C2=AE Core=E2=84=A2 Ultra 7 processors, 8th generation Inte= l=C2=AE Core=E2=84=A2 i3 >>> processors, Intel=C2=AE Xeon=C2=AE E processors, Intel=C2=AE Xeon= =C2=AE 6 P-Core >>> processors, Intel=C2=AE Xeon=C2=AE 6 E-Core processors, and Intel= =C2=AE Series 2 >>> Core=E2=84=A2 Ultra processors >>> >>> Signed-off-by: Teddy Astie >>> --- >>> 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-ffadd9707= 394@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