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

[Jue Wang <juew@google.com>]

On Fri, Apr 29, 2022 at 2:32 PM Jue Wang <juew@google.com> wrote:
>
> On Fri, Apr 29, 2022 at 2:10 PM Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > 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.
>
> This type of scanning is intended to be run on the host side. That
> should avoid concerns around the guest ballooning or any effects to
> the host side reclaim that's based on the guest's working set.
>
> I don't know why a guest wants to spend its CPU cycles and pollute its
> caches etc to run this scanner, anyway. This should be a benefit
> provide by the cloud platform transparently to the guest.

The coverage of a guest scanning its own memory does not provide the
benefit that a host wide scanning can in terms of preventing fatal
system crashes or on memory that affects this guest but is not
accessible to the guest.

>
>
> >
> > 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.
>
> This can be addressed with a different design.