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

Ariadne Conill
2025-12-19T23:19:46Z

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@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 */
> 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