Hi, On Dec 19, 2025, at 8:09 AM, Sean Christopherson <[email protected]> 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
