Re: [PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domU

[Ariadne Conill <ariadne@ariadne.space>]

Hi,

On Dec 19, 2025, at 8:09 AM, Sean Christopherson <seanjc@xxxxxxxxxx> wrote:

On Fri, Dec 19, 2025, Borislav Petkov wrote:

On December 19, 2025 1:01:31 AM UTC, Ariadne Conill <ariadne@ariadne.space> 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 <ariadne@ariadne.space>

>Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx

>Cc: stable@xxxxxxxxxxxxxxx

>---

> 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