[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jiri Denemark
Subject: Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property
Date: Thu, 9 May 2019 17:26:16 +0200
User-agent: Mutt/1.11.4 (2019-03-13)

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

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.

> > 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.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]