On Sat, Apr 19, 2025 at 12:16 AM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > TDG.VP.VMCALL<INSTRUCTION.WBINVD> - Missing > TDG.VP.VMCALL<INSTRUCTION.PCONFIG> - Missing WBINVD and PCONFIG need to be implemented (PCONFIG can be a stub). > TDG.VP.VMCALL<Service.Query> - Missing > TDG.VP.VMCALL<Service.MigTD> - Missing Service needs to be implemented and return Unsupported (0xFFFFFFFE) for all services. > TDG.VP.VMCALL<GETQUOTE> - Have patches, but missing > TDG.VP.VMCALL<SETUPEVENTNOTIFYINTERRUPT> - Have patches, but missing These two need to be supported by userspace and one could say that (therefore) GetTdVmCallInfo would also have to be implemented by userspace. This probably is a good idea in general to leave the door open to more GetTdVmCallInfo leaves. In order to make it easy for userspace to implement GetQuote, it would be nice to have a status for Unsupported listed for GetQuote, because they need to add it anyway for future tdvcalls SetupEventNotifyInterrupt can be a stub if GetQuote is unsupported; therefore it's also trivial for userspace to implement it if the specs adds the "unsupported" return code for GetQuote. > Xiaoyao was tossing around the idea of adding a dedicated "not implemented" > return code too. It could make it simpler to evolve the GHCI spec vs the all or > nothing approach. To me, the main finding here is that we need to have more > clarity on how the GHCI will evolve going forward. I agree that both of these are independently useful, the main action item for KVM being to move TdVmCallInfo to userspace and add support for the other two userspace TDCALLs. Adding WBINVD/PCONFIG/Service is also something that has to be done, but less urgent since nobody is using them. Paolo
