On Mon, 2024-12-02 at 11:07 -0800, Sean Christopherson wrote: > > guest_can_use() is per-vcpu whereas we are currently using the > > CPUID from TD_PARAMS (as per spec) before there are any VCPU's. > > It is a bit of a disconnect so let's keep tsx_supported for now. > > No, as was agreed upon[*], KVM needs to ensure consistency between what KVM > sees > as guest CPUID and what is actually enabled/exposed to the guest. If there > are > no vCPUs, then there's zero reason to snapshot the value in kvm_tdx. And if > there > are vCPUs, then their CPUID info needs to be consistent with respect to > TDPARAMS. Small point - the last conversation[0] we had on this was to let *userspace* ensure consistency between KVM's CPUID (i.e. KVM_SET_CPUID2) and the TDX Module's view. So the configuration goes: 1. Userspace configures per-VM CPU features 2. Userspace gets TDX Module's final per-vCPU version of CPUID configuration via KVM API 3. Userspace calls KVM_SET_CPUID2 with the merge of TDX Module's version, and userspace's desired values for KVM "owned" CPUID leads (pv features, etc) But KVM's knowledge of CPUID bits still remains per-vcpu for TDX in any case. > > - Don't hardcode fixed/required CPUID values in KVM, use available metadata > from TDX Module to reject "bad" guest CPUID (or let the TDX module > reject?). > I.e. don't let a guest silently run with a CPUID that diverges from what > userspace provided. The latest QEMU patches have this fixed bit data hardcoded in QEMU. Then the long term solution is to make the TDX module return this data. Xiaoyao will post a proposal on how the TDX module should expose this soon. > > [*] https://lore.kernel.org/all/20240405165844.1018872-1-seanjc@xxxxxxxxxx [0]https://lore.kernel.org/kvm/CABgObfaobJ=G18JO9Jx6-K2mhZ2saVyLY-tHOgab1cJupOe-0Q@xxxxxxxxxxxxxx/
