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?
