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

[Ariadne Conill <ariadne@ariadne.space>]

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 <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