Re: [PATCH] x86/CPU/AMD: Ignore invalid reset reason value

[Sean Christopherson <seanjc@google.com>]

On Mon, Aug 18, 2025, Borislav Petkov wrote:
> On Mon, Aug 18, 2025 at 07:24:26AM -0700, Sean Christopherson wrote:
> > Most definitely not if the guest owner and host owner are not one and the same.
> > The example use case is where the platform owner is running one of _their_ kernels
> > in a VM, in which case that kernel probably does want to know why the platform
> > reboot.
> 
> Except that can you control who uses that feature? If it ends up being used by
> a VM stack where the guest owner should not know the reboot reason, you've
> lost.

Yeah, but "expose/advertise XYZ to the wrong VM and you've lost" holds true for
so many things.  In all honesty, of the many ways a hypervisor/CSP can screw up,
this one doesn't scare me at all.

> > The same thing that guarantees hardware vendors adhere to specs: the desire to
> > get paid.
> 
> So you're basically saying all HV vendors return -1 for an unimplemented
> register and we should be fine there?

For this type of register, yes, they should.

> > And QEMU did return an error value, 0xffffffff, a.k.a. PCI Master Abort / PCIe
> > Unsupported Request.  I would be amazed if any real world, general purpose VMM
> > did anything else for an MMIO access to an unknown/unsupported range.
> 
> Ok, I guess we will know soon enough. :-)
> 
> > Huh?  Handle a read of all 0xffs as proposed in this patch, and this is unnecessary.
> 
> I don't trust that all HVs will DTRT. But ok, I'll take your word for it.

Heh, I don't I trust hypervisors/VMMs either, but if they don't behave, then we
yell at them and/or send patches.