On Fri, Sep 30, 2016 at 09:29:58AM +0200, Jiri Denemark wrote:
> On Thu, Sep 29, 2016 at 18:14:53 -0300, Eduardo Habkost wrote:
> > Instead of translating the feature name entries when adding
> > property names, store the actual property names in the feature
> > name array.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx>
> > ---
> > Changes series v3 -> v4:
> > * New patch added to series
> > ---
> > target-i386/cpu.c | 31 ++++++++++++++++---------------
> > 1 file changed, 16 insertions(+), 15 deletions(-)
> >
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index 4eaec0e..7795a7c 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @@ -279,11 +279,11 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
> > [FEAT_1_ECX] = {
> > .feat_names = {
> > "pni|sse3" /* Intel,AMD sse3 */, "pclmulqdq|pclmuldq", "dtes64", "monitor",
> > - "ds_cpl", "vmx", "smx", "est",
> > + "ds-cpl", "vmx", "smx", "est",
> > "tm2", "ssse3", "cid", NULL,
> > "fma", "cx16", "xtpr", "pdcm",
> > - NULL, "pcid", "dca", "sse4.1|sse4_1",
> > - "sse4.2|sse4_2", "x2apic", "movbe", "popcnt",
> > + NULL, "pcid", "dca", "sse4.1|sse4-1",
> > + "sse4.2|sse4-2", "x2apic", "movbe", "popcnt",
> > "tsc-deadline", "aes", "xsave", "osxsave",
> > "avx", "f16c", "rdrand", "hypervisor",
> > },
>
> It wasn't quite obvious to me where this means we can't use the names
> with underscores when talking to QEMU. So I tried it and apparently
> underscores are just silently translated to dashes. It's backward
> compatible this way. However, QEMU will always give us the names with
> dashes, which means we have even more differences between libvirt's
> feature names and QEMU's feature names. So assuming we'll have an
> interface for querying supported CPU properties (and their aliases),
> shouldn't the old underscore names be added as aliases? This way, we
> could actually know that "ds-cpl" means "ds_cpl".
Good idea. Instead of translating property names silently we can
add aliases for the ones where underscores were actually used. I
will look into it.
--
Eduardo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list