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

[Eduardo Habkost <ehabkost@redhat.com>]

On Thu, May 09, 2019 at 05:26:16PM +0200, Jiri Denemark wrote:
> On Thu, May 09, 2019 at 10:56:17 -0300, Eduardo Habkost wrote:
> > On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote:
> > > 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?
> 
> Libvirt only knows about a single spelling for each CPU feature and
> quite often it is not the canonical variant. Thus libvirt would only
> recognize features for which the name known by libvirt is the canonical
> name.
> 
> We could theoretically make the translation in libvirt, but it's not
> going to be future proof. If a new spelling is introduced, it's because
> the old one is not considered correct and the new one becomes the
> canonical version. When libvirt doesn't have the translation (libvirt is
> older or just didn't catch up yet) we have a big problem.
> 
> I guess a good alternative would be some way of querying all CPU feature
> names and their aliases. If I'm not mistaken, we can either get a list
> of canonical names or all names, but without any clue which names
> actually refer to a single feature.

Right.  But (as described below) if you want to know the status a
specific feature you already know about (even if you are using
the old spelling), qom-get should work for you.

The goal of filtered-features and unavailable-features is to
catch all the rest: features you might not know about, but that
should prevent a CPU model from running.

> 
> > > 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.
> 
> That's what filtered-features is used for.

Right.  My goal here is to replace filtered-features, not
feature-words.

> 
> As I tried to explain (and apparently failed :-)) we use feature-words
> for a different thing. I guess it will be more clear using a specific
> example. For example, when arat CPU feature was introduced, it was added
> into several existing CPU models and thus libvirt's version of the CPU
> model differs from the one in QEMU. (This is actually safer and better
> then changing the libvirt's CPU model too since migration relies on both
> hosts having the same definition of the CPU model used by a domain.) So,
> for example, when a domain with Broadwell CPU model is started, libvirt
> checks feature-words to see whether some CPU features not defined in
> libvirt's definition of Broadwell CPU model were enabled. And it will
> see arat. As a result the live domain definition will actually be
> changed to Broadwell+arat to make sure arat is not lost after migration.
> 
> Is the usage clear now?
> 
> Anyway, I think we can just check all features we know about via CPU
> properties to get the same result. It's not going to be as nice as using
> feature-words, but it's doable.

For the use case you describe here, qom-get sounds better than
using feature-words, yes.

-- 
Eduardo