Hi,
On 12/19/25 08:09, Sean Christopherson wrote:
On Fri, Dec 19, 2025, Borislav Petkov wrote:
On December 19, 2025 1:01:31 AM UTC, Ariadne Conill <[email protected]>
wrote:
Xen domU cannot access the given MMIO address for security reasons,
resulting in a failed hypercall in ioremap() due to permissions.
Why does that matter though? Ah, because set_pte() assumes success, and so
presumably the failed hypercall goes unnoticed and trying to access the MMIO
#PFs due to !PRESENT mapping.
Yes, which results in the guest panicing on Zen platforms.
Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset")
Signed-off-by: Ariadne Conill <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/x86/kernel/cpu/amd.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a6f88ca1a6b4..99308fba4d7d 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -29,6 +29,8 @@
# include <asm/mmconfig.h>
#endif
+#include <xen/xen.h>
+
#include "cpu.h"
u16 invlpgb_count_max __ro_after_init = 1;
@@ -1333,6 +1335,10 @@ static __init int print_s5_reset_status_mmio(void)
if (!cpu_feature_enabled(X86_FEATURE_ZEN))
return 0;
+ /* Xen PV domU cannot access hardware directly, so bail for domU case */
Heh, Xen on Zen crime.
+ if (cpu_feature_enabled(X86_FEATURE_XENPV) && !xen_initial_domain())
+ return 0;
+
addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
if (!addr)
return 0;
Sean, looka here. The other hypervisor wants other checks.
Time to whip out the X86_FEATURE_HYPERVISOR check.
LOL, Ariadne, be honest, how much did Boris pay you? :-D
Nothing :)
At Edera we have been running with this patch for a few months, I just
forgot to upstream it.
I was reminded of this patch when an Alpine user opened a bug[0]
demonstrating the same behavior on 6.18.
[0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17789
Jokes aside, I suppose I'm fine adding a HYPERVISOR check, but at the same time,
how is this not a Xen bug? Refusing to create a mapping because the VM doesn't
have a device defined at a given GPA is pretty hostile behavior for a
hypervisor.
I think it would be better to fix this in a more generic way if we can.
Ariadne
