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:
> 1. Reading via direct mapping from guest private memory should not
> generate #MC and it should result in expected memory error poisoning
> behavior (to be confirmed).
> 
> 2. Reading via direct mapping from SEV-SNP guest private memory does
> not generate #MC or #PF.

There are two different things you need to look at here:

1. What is the *implementation* today?
2. What is the architecture to which the hardware vendors will commit?

Let's say that, today, a TDX host accessing guest-private memory doesn't
trigger the error handling that you want.  Then, this scheme simply
won't work on today's TDX hardware.  You can only hope for better
hardware in the future.

Now, consider if you get lucky: Today, a TDX host accessing
guest-private memory *DOES* trigger the error handling that you want.
That's great, but it doesn't mean that the behavior will stick.  Intel
might change it _tomorrow_ without telling anyone because folks believe
it to be software-invisible.

Either way, you need to extract promises from hardware vendors if you
want to depend on this scheme.