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. Could you explain the use case you have in mind, so we can look for alternatives? > > 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. I guess it depends on your goal: If your just want to know if one specific feature is missing for some reason, you can check the QOM properties directly. That's OK, and it's even better than checking the `feature-words` property. If you want to be 100% sure no property was missing when starting the VM (e.g. emulate the behavior of the "enforce" option), I suggest you check if `unavailable-features` is empty. -- Eduardo