Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/04/2024 4:18 am, Xiaoyao Li wrote:
On 4/10/2024 12:13 AM, Xiaoyao Li wrote:
On 4/9/2024 11:49 PM, Edgecombe, Rick P wrote:
I don't want JSON.  I want a data payload that is easily consumable in C code, which contains (a) the bits that are fixed and (b) their values.  If a value
can
change at runtime, it's not fixed.
Right. The fixed values have to come in a reasonable format from the TDX module at runtime, or require an opt-in for any CPUID bits to change in future TDX
modules.

I have a thought for current situation that TDX module doesn't report fixed CPUID bits via SEAMCALL interface but defines them in docs. VMM (KVM or userspace) can maintain a hardcoded array of fixed CPUID bits and their values according to TDX docs.  And VMM needs to update the fixed array by striping out the bits that are reported in TDSYSINFO.CPUID_CONFIG[], which are configurable.

If the newer TDX module changes some fixed bits to configurable bits, They will show up in TDSYSINFO.CPUID_CONFIG[]. So VMM can update fixed array correctly.

In fact, this is how TDX QEMU series current implements.

However, it requires TDX module to follow the rule that if any bit becomes not fixed, it needs to be reported in TDSYSINFO.CPUID_CONFIG[] as configurable.

If TDX module flips the bit between fixed0 and fixed1. It doesn't work neither. :(

Exactly. I think we need to ask TDX module to report such information rather than depending on some JASON file.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux