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? As you mentioned, there are two interesting QOM properties: filtered-features and feature-words and both are used by libvirt. We use feature-words to get CPU features which were enabled in the guest CPU on top of what we expected. This is the case of, e.g., a feature added to a given CPU model for new machine types. I guess we could switch to checking QOM properties for individual features as a replacement for feature-words which covers both CPUID and MSR features. Jirka