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