On 9/15/2026 12:14 AM, Edgecombe, Rick P wrote: > On Mon, 2026-09-14 at 15:04 +0800, Binbin Wu wrote: >>> Note, an equivalent TDX side implementation is missing. No TDX module >>> with FRED support exists yet so this would be an issue for future >>> platforms. A generic discussion regarding this is ongoing at: >>> https://lore.kernel.org/kvm/[email protected]/ >> >> For old KVM versions, we want to defer the opt-in design or backport >> decision. >> ( >> https://lore.kernel.org/kvm/[email protected] >> m/) >> >> We may finally choose to backport the TDX CPUID filtering patch series to >> stable kernels. If this patch series lands first, should we add FRED in the >> deny list for TDX as a temporary solution to avoid having some version(s) >> that >> allow FRED for TDX without FRED support in KVM? > > The specific FRED problem starts with FRED host usage + TDX, so I don't think > there is a reason to tie and temporary fixups to VMX FRED support, in any > case. > Or were you thinking to blame userspace for not respecting > KVM_GET_SUPPORTED_CPUID, which would change after this series?
My concern is if there is a release x with this patch set, but the release is not a LTS/stable kernel branch. Then backporting of TDX CPUID filtering patch series will skip this release. When the TDX module with FRED support released and work with the kernel release, it will have problem. > > Since there are plenty of released kernels with FRED host support already, I'd > think to wait until we settle the opt-in question. Which doesn't seem like it > should be too much longer. It will be less thrash. OK
