All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Dave Hansen <dave.hansen@intel.com>, Borislav Petkov <bp@alien8.de>
Cc: Nikunj A Dadhania <nikunj@amd.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
	hpa@zytor.com, xin@zytor.com, seanjc@google.com,
	pbonzini@redhat.com, x86@kernel.org, sohil.mehta@intel.com,
	jon.grimm@amd.com
Subject: Re: [PATCH v2 1/2] x86/cpu: Disable CR pinning during CPU bringup
Date: Mon, 9 Mar 2026 13:40:21 -0500	[thread overview]
Message-ID: <7ca205d6-b01b-4ed3-959d-db31a6496d79@amd.com> (raw)
In-Reply-To: <70644e1d-dd0e-4f0f-81c0-fd095e46e50b@intel.com>

On 3/9/26 13:03, Dave Hansen wrote:
> On 3/9/26 09:15, Borislav Petkov wrote:
>> On Mon, Mar 09, 2026 at 08:38:10AM -0700, Dave Hansen wrote:
>>> On 3/9/26 06:46, Borislav Petkov wrote:
>>>> My SNP guest stops booting with this right:
>>> Could you dump out CR4 at wakeup_cpu_via_vmgexit() before and after this
>>> patch? Right here:
>>>
>>>         /* CR4 should maintain the MCE value */
>>>         cr4 = native_read_cr4() & X86_CR4_MCE;
>>>
>>> It's got to be some delta there.
>> Looks the same to me:
>>
>> before:      31  SEV: wakeup_cpu_via_vmgexit: CR4: 0x3506f0
>>
>> That's 31 CPUs - no BSP with the CR4 value above.
>>
>> after: [    3.354326] SEV: wakeup_cpu_via_vmgexit: CR4: 0x3506f0
>>
>> That stops after CPU1, i.e., the first AP. But the CR4 value is the same.
> 
> The only pinned bits in there are: SMAP, SMEP and FSGSBASE.
> 
> SMAP and SMEP are unlikely to be biting us here.
> 
> FSGSBASE is _possible_ but I don't see any of the {RD,WR}{F,G}SBASE
> instructions in early boot where it would bite us.
> 
> Can you boot this thing without FSGSBASE support?
> 
> The other option would be to boot a working system, normally and see
> what is getting flipped by pinning at cr4_init(). The attached patch
> does that. It also uses trace_printk() so it hopefully won't trip over
> #VC's during early boot with the console.
> 
> For me, it's flipping on 0x310800, which is:
> 
> 	#define X86_CR4_OSXMMEXCPT      (1ul << 10)
> 	#define X86_CR4_FSGSBASE        (1ul << 16)
> 	#define X86_CR4_SMEP            (1ul << 20)
> 	#define X86_CR4_SMAP            (1ul << 21)
> 
> *Maybe* the paranoid entry code is getting called from the #VC handler
> in early boot? It has ALTERNATIVEs on X86_FEATURE_FSGSBASE and might be
> using the FSGSBASE instructions in there.

Could be... before the patch the AP CR4 value is:

[    0.020362] *** DEBUG: cr4_init - cr4=0x3100f0

after the patch it is:

[    0.020284] *** DEBUG: cr4_init - cr4=0xf0

The SNP guest is dying in __x2apic_enable() when trying to read
MSR_IA32_APICBASE, which will trigger a #VC.

If I set CR4[16] in cr4_init() then the SNP guest boots fine.

Thanks,
Tom



  reply	other threads:[~2026-03-09 18:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26  9:23 [PATCH v2 0/2] x86/fred: Fix SEV-ES/SNP guest boot failures Nikunj A Dadhania
2026-02-26  9:23 ` [PATCH v2 1/2] x86/cpu: Disable CR pinning during CPU bringup Nikunj A Dadhania
2026-03-09 13:46   ` Borislav Petkov
2026-03-09 15:38     ` Dave Hansen
2026-03-09 16:15       ` Borislav Petkov
2026-03-09 18:03         ` Dave Hansen
2026-03-09 18:40           ` Tom Lendacky [this message]
2026-03-09 19:27             ` Dave Hansen
2026-03-11 10:41               ` Nikunj A. Dadhania
2026-03-11 14:07                 ` Dave Hansen
2026-03-11 15:42                   ` Nikunj A. Dadhania
2026-03-11 17:28                     ` Dave Hansen
2026-03-12  7:21                       ` Nikunj A. Dadhania
2026-03-12  7:26                         ` Nikunj A. Dadhania
2026-03-12 14:08                       ` Nikunj A. Dadhania
2026-03-12 14:20                         ` Dave Hansen
2026-03-12 14:53                           ` Nikunj A. Dadhania
2026-03-12 15:02                             ` Dave Hansen
2026-03-12 19:06                               ` David Laight
2026-03-16 20:27                           ` Chang S. Bae
2026-03-16 21:43                             ` Dave Hansen
2026-03-17  4:12                               ` Nikunj A. Dadhania
2026-03-17 14:26                                 ` Borislav Petkov
2026-03-17 15:31                                 ` Dave Hansen
2026-03-17 16:54                                   ` Borislav Petkov
2026-03-18  8:19                                     ` Nikunj A. Dadhania
2026-03-17 17:04                               ` Chang S. Bae
2026-03-17 17:51                                 ` Chang S. Bae
2026-03-12 18:09                         ` Sohil Mehta
2026-03-13  8:35                           ` Nikunj A. Dadhania
2026-03-13 18:05                             ` Sohil Mehta
2026-03-13 19:10                               ` Borislav Petkov
2026-03-17 17:06                             ` Chang S. Bae
2026-02-26  9:23 ` [PATCH v2 2/2] x86/fred: Fix early boot failures on SEV-ES/SNP guests Nikunj A Dadhania
2026-02-26 14:14   ` Tom Lendacky
2026-02-27  4:14     ` Nikunj A. Dadhania

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ca205d6-b01b-4ed3-959d-db31a6496d79@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jon.grimm@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.