On Tue, Dec 10, 2024, Rick P Edgecombe wrote: > On Tue, 2024-12-10 at 11:22 +0800, Xiaoyao Li wrote: > > > The solution in this proposal decreases the work the VMM has to do, but > > > in the long term won't remove hand coding completely. As long as we are > > > designing something, what kind of bar should we target? > > > > For this specific #VE reduction case, I think userspace doesn't need to > > do any hand coding. Userspace just treats the bits related to #VE > > reduction as configurable as reported by TDX module/KVM. And userspace > > doesn't care if the value seen by TD guest is matched with what gets > > configured by it because they are out of control of userspace. > > Besides a specific problem, here reduced #VE is also an example of increasing > complexity for TD CPUID. If we have more things like it, it could make this > interface too rigid. I agree with Rick in that having QEMU treat them as configurable is going to be a disaster. But I don't think it's actually problematic in practice. If QEMU (or KVM) has no visibility into the state of the guest's view of the affected features, then it doesn't matter whether they are fixed or configurable. They're effectively Schrödinger's bits: until QEMU/KVM actually looks at them, they're neither dead nor alive, and since QEMU/KVM *can't* look at them, who cares? So, if the TDX Module *requires* them to be set/cleared when the TD is created, then they should be reported as fixed. If the TDX module doesn't care, then they should be reported as configurable. The fact that the guest can muck with things under the hood doesn't factor into that logic. If TDX pulls something like this for features that KVM cares about, then we have problems, but that's already true today. If a feature requires KVM support, it doesn't really matter if the feature is fixed or configurable. What matters is that KVM has a chance to enforce that the feature can be used by the guest if and only if KVM has the proper support in place. Because if KVM is completely unaware of a feature, it's impossible for KVM to know that the feature needs to be rejected. This isn't unique to TDX, CoCo, or firmware. Every new feature that lands in hardware needs to either be "benign" or have the appropriate virtualization controls. KVM already has to deal with cases where features can effectively be used without KVM's knowledge. E.g. there are plenty of instruction-level virtualization holes, and SEV-ES doubled down by essentially forcing KVM to let the guest write XCR0 and XSS directly. It all works, so long as the hardware vendor doesn't screw up and let the guest use a feature that impacts host safety and/or functionality, without the hypervisor's knowledge. So, just don't screw up :-)
