On Fri, Apr 29, 2022 at 2:10 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > On 4/29/22 12:46, Jue Wang wrote: > > Per seanjc@xxxxxxxxxx: > > 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. > > 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.
