Re: [PATCH v19 059/130] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases

[Edgecombe, Rick P]

On Thu, 2024-03-21 at 15:59 -0700, Isaku Yamahata wrote:
> > 
> > Ok, I see now how this works. MTRRs and APIC zapping happen to use
> > the
> > same function: kvm_zap_gfn_range(). So restricting that function
> > from
> > zapping private pages has the desired affect. I think it's not
> > ideal
> > that kvm_zap_gfn_range() silently skips zapping some ranges. I
> > wonder
> > if we could pass something in, so it's more clear to the caller.
> > 
> > But can these code paths even get reaches in TDX? It sounded like
> > MTRRs
> > basically weren't supported.
> 
> We can make the code paths so with the (new) assumption that guest
> MTRR can
> be disabled cleanly.

So the situation is (please correct):
KVM has a no "making up architectural behavior" rule, which is an
important one. But TDX module doesn't support MTRRs. So TD guests can't
have architectural behavior for MTRRs. So this patch is trying as best
as possible to match what MTRR behavior it can (not crash the guest if
someone tries).

First of all, if the guest unmaps the private memory, doesn't it have
to accept it again when gets re-added? So will the guest not crash
anyway?

But, I guess we should punt to userspace is the guest tries to use
MTRRs, not that userspace can handle it happening in a TD...  But it
seems cleaner and safer then skipping zapping some pages inside the
zapping code.

I'm still not sure if I understand the intention and constraints fully.
So please correct. This (the skipping the zapping for some operations)
is a theoretical correctness issue right? It doesn't resolve a TD
crash?