Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

[Eduardo Habkost]

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