On Tue, Dec 10, 2024 at 11:22:39AM +0800, Xiaoyao Li wrote: > On 12/7/2024 2:41 AM, Edgecombe, Rick P wrote: > > As we've been working on this, I've started to wonder whether this is a halfway > > solution that is not worth it. Today there are directly configurable bits, > > XFAM/attribute controlled bits, other opt-ins (like #VE reduction). And this has > > only gotten more complicated as time has gone on. > > > > If we really want to fully solve the problem of userspace understanding which > > configurations are possible, the TDX module would almost need to expose some > > sort of CPUID logic DSL that could be used to evaluate user configuration. > > > > On the other extreme we could just say, this kind of logic is just going to need > > to be hand coded somewhere, like is currently done in the QEMU patches. > > I think hand coded some specific handling for special case is acceptable > when it's unavoidable. However, an auto-adaptive interface for general cases > is always better than hand code/hard code something. E.g., current QEMU > implementation hardcodes the fixed0 and fixed1 information based on TDX > 1.5.06 spec. When different versions of TDX module have different fixed0 and > fixed1 information, QEMU will needs interface to get the version of TDX > module and maintain different information for each version of TDX module. > It's a disaster IMHO. While it would be nice to have the data available for the configuration options, the code configuring the settings in QEMU still needs to understand the meaning of the configuration options. So having the configurable options data available in QEMU may not be that much better from setting the information based on the detected version. Maybe the revision specific information needed could be in a Linux header file so kernel can use it too? Regards, Tony
