Re: [RFC] Expose a memory poison detector ioctl to user space.

[Dave Hansen <dave.hansen@intel.com>]

On 4/29/22 12:46, Jue Wang wrote:
> Per seanjc@google.com:
> TDX doesn't support #MC exception injection, but IRQ "injection" via
> posted interrupts is supported. Accesses to machine check MSRs will
> #VE, i.e. can be emulated by KVM, so CMCI should work fine for TDX
> guests.
> 
> Proactively scanning for memory error should benefit TDX guests
> preventing potential host shutdowns.

It also need to know to avoid unaccepted memory in TDX guests at *least*.

> It seems the current proposed design can cover TDX & SEV-SNP if the
> direct mapping to guest private memory is preserved?

I wouldn't go that far.  The unaccepted TDX guest memory thing is just
the obvious one at the moment.  There are a whole ton of other guest
ballooning mechanisms out there and I'm not sure that all of them are
happy to let you touch ballooned-away memory.

But, the bigger issue is that those cases had not even been considered.
 It means that there is a *LOT* of homework needed to seek out and cover
all the other weird cases.

I also think the proposed ABI -- exposing physical addresses to
userspace as a part of the design -- is an utter non-starter.