[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/CPU/AMD: Don't print reset reason in VMs
- To: Jason Andryuk <jason.andryuk@xxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, x86@xxxxxxxxxx, "H. Peter Anvin" <hpa@xxxxxxxxx>, Yazen Ghannam <yazen.ghannam@xxxxxxx>
- From: Mario Limonciello <superm1@xxxxxxxxxx>
- Date: Wed, 4 Nov 2026 09:31:42 -0600
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="Date:Subject:To:Cc:References:From:In-Reply-To"
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Ariadne Conill <ariadne@ariadne.space>, Sean Christopherson <seanjc@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, stable@xxxxxxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
- Delivery-date: Wed, 04 Nov 2026 15:31:53 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11/3/26 19:30, Jason Andryuk wrote:
print_s5_reset_status_mmio() expects to read FCH MMIO on baremetal. VMs
don't have emulated FCH registers, so there is nothing to check. Add an
early exit when running on a hypervisor.
The real motivation is Xen PV domUs can't boot on Zen CPUs. PV domUs
PTE contain system physical addresses - they don't have concept of guest
physical addresses. domUs can only map physical addresses they are
assigned, so a domU fails to map the FCH MMIO addresses. However
set_pte() does not return failure, so ioremap() returns a pointer while
the PTEs are unpopulated. print_s5_reset_status_mmio() faults when
reading through the pointer, breaking the boot. This change fixes Xen
PV domUs booting on Zen CPUs.
dom0 can map the FCH MMIO, but it has X86_FEATURE_HYPERVISOR set. With
this change, it no longer prints the reset reason.
Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset")
Cc: stable@xxxxxxxxxxxxxxx
Suggested-by: Borislav Petkov <bp@xxxxxxxxx>
Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
---
dom0 could work, but that would require a xen_initial_domain() check.
I've wondered about a different approach: We can't directly check for a
device for the FCH_PM_BASE memory, but maybe we could check for a PCI
ISA Bridge with PCI_VENDOR_ID_AMD. That might be close enough to
indicate real hardware? But it would still be a heuristic, so I'm not
sure how much better that would be.
---
arch/x86/kernel/cpu/amd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 40463bad1078..580ccc2ce5fc 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1357,7 +1357,8 @@ static __init int print_s5_reset_status_mmio(void)
u32 value;
int i;
- if (!cpu_feature_enabled(X86_FEATURE_ZEN))
+ if (!cpu_feature_enabled(X86_FEATURE_ZEN) ||
+ cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
return 0;
addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
Reviewed-by: Mario Limonciello (AMD) <superm1@xxxxxxxxxx>
|