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