On Wed, Aug 14, 2024, Chao Gao wrote: > On Tue, Aug 13, 2024 at 11:14:31PM +0800, Xiaoyao Li wrote: > >On 8/13/2024 7:34 PM, Chao Gao wrote: > >> I think adding new fixed-1 bits is fine as long as they don't break KVM, i.e., > >> KVM shouldn't need to take any action for the new fixed-1 bits, like > >> saving/restoring more host CPU states across TD-enter/exit or emulating > >> CPUID/MSR accesses from guests > > > >I disagree. Adding new fixed-1 bits in a newer TDX module can lead to a > >different TD with same cpu model. > > The new TDX module simply doesn't support old CPU models. What happens if the new TDX module is needed to fix a security issue? Or if a customer wants to support a heterogenous migration pool, and older (physical) CPUs don't support the feature? Or if a customer wants to continue hosting existing VM shapes on newer hardware? > QEMU can report an error and define a new CPU model that works with the TDX > module. Sometimes, CPUs may drop features; Very, very rarely. And when it does happen, there are years of warning before the features are dropped. > this may cause KVM to not support some features and in turn some old CPU > models having those features cannot be supported. is it a requirement for > TDX modules alone that old CPU models must always be supported? Not a hard requirement, but a pretty firm one. There needs to be sane, reasonable behavior, or we're going to have problems.
