On Thu, 9 May 2019 10:56:17 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote: > > On Mon, Apr 22, 2019 at 20:47:40 -0300, Eduardo Habkost wrote: > > > Currently, libvirt uses the "filtered-features" QOM property at > > > runtime to ensure no feature was accidentally disabled on VCPUs > > > because it's not available on the host. > > > > > > However, the code for "feature-words" assumes that all missing > > > features have a corresponding CPUID bit, which is not true for > > > MSR-based features like the ones at FEAT_ARCH_CAPABILITIES. > > > > > > We could extend X86CPUFeatureWordInfo to include information > > > about MSR features, but it's impossible to do that while keeping > > > compatibility with clients that (reasonably) expect all elements > > > of "filtered-features" to have the cpuid-* fields. > > > > > > We have a field in "query-cpu-definitions" that already describes > > > all features that are missing on a CPU, including MSR features: > > > CpuDefinitionInfo.unavailable-features. The existing code for > > > building the unavailable-features array even uses > > > X86CPU::filtered_features to build the feature list. > > > > > > This series adds a "unavailable-features" QOM property to X86CPU > > > objects that have the same semantics of "unavailable-features" on > > > query-cpu-definitions. The new property has the same goal of > > > "filtered-features", but is generic enough to let any kind of CPU > > > feature to be listed there without relying on low level details > > > like CPUID leaves or MSR numbers. > > > > Thanks. > > > > Would this unavailable-features property contain only canonical names of > > the features or all possible aliases of all features? For example, > > "tsc-adjust" can also be spelled as "tsc_adjust". When calling > > query-cpu-model-expansion, we have a way to request all variants by > > running full expansion on the result of a previous static expansion. Can > > we get something like this for unavailable-features too? > > I'd like to avoid that, and refer only to the canonical names. Can we deprecate aliases to avoid confusion in future? (there aren't that many of them that used pre-QOM name format)
