[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrwFWiSQc6pRHrCG@google.com>
Date: Tue, 13 Aug 2024 18:16:10 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: Xiaoyao Li <xiaoyao.li@...el.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>,
pbonzini@...hat.com, kvm@...r.kernel.org, kai.huang@...el.com,
isaku.yamahata@...il.com, tony.lindgren@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 25/25] KVM: x86: Add CPUID bits missing from KVM_GET_SUPPORTED_CPUID
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.
Powered by blists - more mailing lists