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

["Teddy Astie" <teddy.astie@vates.tech>]

Le 19/12/2025 à 18:40, Sean Christopherson a écrit :
> On Fri, Dec 19, 2025, Teddy Astie wrote:
>> 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@lists.xenproject.org
>>> Cc: stable@vger.kernel.org
>>> ---
>>>    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).
>
> IMO, terminating an SEV-ES+ guest because it accesses an unknown MMIO range is
> unequivocally a hypervisor bug.

Terminating may be a bit excessive, but the hypervisor can respond #GP
to either unexpected MMIO-NAE and NPF-AE if it doesn't know how to deal
with this MMIO/NPF (xAPIC has a similar behavior when it is disabled).

> The right behavior there is to configure a reserved NPT entry
> to reflect the access into the guest as a #VC.

I'm not sure this is the best approach, that would allow the guest to
trick the hypervisor into making a unbounded amount of reserved entries.

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech