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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Le 19/12/2025 à 02:04, Ariadne Conill a écrit :
> Xen domU cannot access the given MMIO address for security reasons,
> resulting in a failed hypercall in ioremap() due to permissions.
>
> 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 */
> +     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;

Such MMIO only has a meaning in a physical machine, but the feature
check is bogus as being on Zen arch is not enough for ensuring this.

I think this also translates in most hypervisors with odd reset codes
being reported; without being specific to Xen PV (Zen CPU is
unfortunately not enough to ensuring such MMIO exists).

Aside that, attempting unexpected MMIO in a SEV-ES/SNP guest can cause
weird problems since they may not handled MMIO-NAE and could lead the
hypervisor to crash the guest instead (unexpected NPF).

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech