On Mon, 2025-02-03 at 12:33 -0800, Sean Christopherson wrote: > > Since there is no upstream KVM TDX support yet, why isn't it an option to > > still > > revert the EDKII commit too? It was a relatively recent change. > > I'm fine with that route too, but it too is a band-aid. Relying on the > *untrusted* > hypervisor to essentially communicate memory maps is not a winning strategy. > > > To me it seems that the normal KVM MTRR support is not ideal, because it is > > still lying about what it is doing. For example, in the past there was an > > attempt to use UC to prevent speculative execution accesses to sensitive > > data. > > The KVM MTRR support only happens to work with existing guests, but not all > > possible MTRR usages. > > > > Since diverging from the architecture creates loose ends like that, we could > > instead define some other way for EDKII to communicate the ranges to the > > kernel. > > Like some simple KVM PV MSRs that are for communication only, and not > > Hard "no" to any PV solution. This isn't KVM specific, and as above, bouncing > through the hypervisor to communicate information within the guest is asinine, > especially for CoCo VMs. Hmm, right. So the other options could be: 1. Some TDX module feature to hold the ranges: - Con: Not shared with AMD 2. Re-use MTRRs for the communication, revert changes in guest and edk2: - Con: Creating more half support, when it's technically not required - Con: Still bouncing through the hypervisor - Pro: Design and code is clear 3. Create some new architectural definition, like a bit that means "MTRRs don't actually work: - Con: Takes a long time, need to get agreement - Con: Still bouncing through the hypervisor - Pro: More pure solution 4. Do this series: - Pro: Looks ok to me - Cons: As explained in the patches, it's a bit hacky. - Cons: Could there be more cases than the legacy PCI hole? I would kind of like to see something like 3, but 2 or 4 seem the only feasible ones if we want to resolve this soon.
