[RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[David Edmondson]

Currently "-cpu -feature,+feature" will disable -feature, which seems
contrary to the intention of the user. Fix this such that the later
flag wins. There are no changes to the interaction of +/- and =on/=off.

Enabling KVM currently causes a default set of KVM features to be
enabled. Allow this default set to be defeated, requiring all features
to be explicitly enabled.

David Edmondson (1):
  hw/i386: -cpu model,-feature,+feature should enable feature

Joao Martins (1):
  target/i386: Add "-cpu +kvm-no-defaults"

 target/i386/cpu.c                   | 38 +++++++++++++++++++++++------
 target/i386/cpu.h                   |  3 +++
 tests/qtest/test-x86-cpuid-compat.c |  8 +++---
 3 files changed, 38 insertions(+), 11 deletions(-)

-- 
2.29.2

[RFC PATCH 1/2] hw/i386: -cpu model, -feature, +feature should enable feature

[David Edmondson]

"Minus" features are applied after "plus" features, so ensure that a
later "plus" feature causes an earlier "minus" feature to be removed.

This has no effect on the existing "-feature,feature=on" backward
compatibility code (which warns and turns the feature off).

Signed-off-by: David Edmondson <david.edmondson@oracle.com>
---
 target/i386/cpu.c                   | 33 +++++++++++++++++++++++------
 tests/qtest/test-x86-cpuid-compat.c |  8 +++----
 2 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 35459a38bb..13f58ef183 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4750,13 +4750,32 @@ static void x86_cpu_parse_featurestr(const char *typename, char *features,
         GlobalProperty *prop;
 
         /* Compatibility syntax: */
-        if (featurestr[0] == '+') {
-            plus_features = g_list_append(plus_features,
-                                          g_strdup(featurestr + 1));
-            continue;
-        } else if (featurestr[0] == '-') {
-            minus_features = g_list_append(minus_features,
-                                           g_strdup(featurestr + 1));
+        if (featurestr[0] == '+' || featurestr[0] == '-') {
+            const char *feat = featurestr + 1;
+            GList **remove, **add;
+            GList *val;
+
+            if (featurestr[0] == '+') {
+                remove = &minus_features;
+                add = &plus_features;
+            } else {
+                remove = &plus_features;
+                add = &minus_features;
+            }
+
+            val = g_list_find_custom(*remove, feat, compare_string);
+            if (val) {
+                char *data = val->data;
+
+                *remove = g_list_remove(*remove, data);
+                g_free(data);
+            }
+
+            val = g_list_find_custom(*add, feat, compare_string);
+            if (!val) {
+                *add = g_list_append(*add, g_strdup(feat));
+            }
+
             continue;
         }
 
diff --git a/tests/qtest/test-x86-cpuid-compat.c b/tests/qtest/test-x86-cpuid-compat.c
index 7ca1883a29..6824d2b13e 100644
--- a/tests/qtest/test-x86-cpuid-compat.c
+++ b/tests/qtest/test-x86-cpuid-compat.c
@@ -171,18 +171,18 @@ static void test_plus_minus_subprocess(void)
     char *path;
 
     /* Rules:
-     * 1)"-foo" overrides "+foo"
+     * 1) The later of "+foo" or "-foo" wins
      * 2) "[+-]foo" overrides "foo=..."
      * 3) Old feature names with underscores (e.g. "sse4_2")
      *    should keep working
      *
-     * Note: rules 1 and 2 are planned to be removed soon, and
-     * should generate a warning.
+     * Note: rule 2 is planned to be removed soon, and should generate
+     * a warning.
      */
     qtest_start("-cpu pentium,-fpu,+fpu,-mce,mce=on,+cx8,cx8=off,+sse4_1,sse4_2=on");
     path = get_cpu0_qom_path();
 
-    g_assert_false(qom_get_bool(path, "fpu"));
+    g_assert_true(qom_get_bool(path, "fpu"));
     g_assert_false(qom_get_bool(path, "mce"));
     g_assert_true(qom_get_bool(path, "cx8"));
 
-- 
2.29.2

[RFC PATCH 2/2] target/i386: Add "-cpu +kvm-no-defaults"

[David Edmondson]

From: Joao Martins <joao.m.martins@oracle.com>

When enabling reporting to the guest that the hypervisor is KVM via
"+kvm", we also enable all of the known KVM features that are
supported by the host kernel. A new "kvm-no-defaults" option for -cpu
defeats this, enabling KVM reporting but *not* enabling any specific
KVM features. Those features can be enabled one-by-one using existing
feature flags, such as kvmclock, kvm-pv-eoi, etc.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
---
 target/i386/cpu.c | 5 +++++
 target/i386/cpu.h | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 13f58ef183..4f1e807815 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6398,6 +6398,10 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
     int i;
     GList *l;
 
+    if (kvm_enabled() && cpu->kvm_no_defaults) {
+        env->features[FEAT_KVM] = 0;
+    }
+
     for (l = plus_features; l; l = l->next) {
         const char *prop = l->data;
         if (!object_property_set_bool(OBJECT(cpu), prop, true, errp)) {
@@ -7269,6 +7273,7 @@ static Property x86_cpu_properties[] = {
     DEFINE_PROP_BOOL("cpuid-0xb", X86CPU, enable_cpuid_0xb, true),
     DEFINE_PROP_BOOL("lmce", X86CPU, enable_lmce, false),
     DEFINE_PROP_BOOL("l3-cache", X86CPU, enable_l3_cache, true),
+    DEFINE_PROP_BOOL("kvm-no-defaults", X86CPU, kvm_no_defaults, false),
     DEFINE_PROP_BOOL("kvm-no-smi-migration", X86CPU, kvm_no_smi_migration,
                      false),
     DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d23a5b340a..f76af4a771 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1744,6 +1744,9 @@ struct X86CPU {
     /* if set, limit maximum value for phys_bits when host_phys_bits is true */
     uint8_t host_phys_bits_limit;
 
+    /* Don't automatically enable all of the discovered KVM features. */
+    bool kvm_no_defaults;
+
     /* Stop SMI delivery for migration compatibility with old machines */
     bool kvm_no_smi_migration;
 
-- 
2.29.2

Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Eduardo Habkost]

Hi,

Thanks for the patch.  Getting rid of special -feature/+feature
behavior was in our TODO list for a long time.

On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
> "Minus" features are applied after "plus" features, so ensure that a
> later "plus" feature causes an earlier "minus" feature to be removed.
> 
> This has no effect on the existing "-feature,feature=on" backward
> compatibility code (which warns and turns the feature off).

If we are changing behavior, why not change behavior of
"-feature,feature=on" at the same time?  This would allow us to
get rid of plus_features/minus_features completely and just make
+feature/-feature synonyms to feature=on/feature=off.

> 
> Signed-off-by: David Edmondson <david.edmondson@oracle.com>
> ---
>  target/i386/cpu.c                   | 33 +++++++++++++++++++++++------
>  tests/qtest/test-x86-cpuid-compat.c |  8 +++----
>  2 files changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 35459a38bb..13f58ef183 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4750,13 +4750,32 @@ static void x86_cpu_parse_featurestr(const char *typename, char *features,
>          GlobalProperty *prop;
>  
>          /* Compatibility syntax: */
> -        if (featurestr[0] == '+') {
> -            plus_features = g_list_append(plus_features,
> -                                          g_strdup(featurestr + 1));
> -            continue;
> -        } else if (featurestr[0] == '-') {
> -            minus_features = g_list_append(minus_features,
> -                                           g_strdup(featurestr + 1));
> +        if (featurestr[0] == '+' || featurestr[0] == '-') {
> +            const char *feat = featurestr + 1;
> +            GList **remove, **add;
> +            GList *val;
> +
> +            if (featurestr[0] == '+') {
> +                remove = &minus_features;
> +                add = &plus_features;
> +            } else {
> +                remove = &plus_features;
> +                add = &minus_features;
> +            }
> +
> +            val = g_list_find_custom(*remove, feat, compare_string);
> +            if (val) {
> +                char *data = val->data;
> +
> +                *remove = g_list_remove(*remove, data);
> +                g_free(data);
> +            }
> +
> +            val = g_list_find_custom(*add, feat, compare_string);
> +            if (!val) {
> +                *add = g_list_append(*add, g_strdup(feat));
> +            }

I believe we'll be able to get rid of plus_features/minus_features
completely if we remove compatibility of "-feature,feature=on".
But if we don't, wouldn't it be simpler to replace
plus_features/minus_features with a single list, appending items
in the order they appear?

> +
>              continue;
>          }
>  
> diff --git a/tests/qtest/test-x86-cpuid-compat.c b/tests/qtest/test-x86-cpuid-compat.c
> index 7ca1883a29..6824d2b13e 100644
> --- a/tests/qtest/test-x86-cpuid-compat.c
> +++ b/tests/qtest/test-x86-cpuid-compat.c
> @@ -171,18 +171,18 @@ static void test_plus_minus_subprocess(void)
>      char *path;
>  
>      /* Rules:
> -     * 1)"-foo" overrides "+foo"
> +     * 1) The later of "+foo" or "-foo" wins
>       * 2) "[+-]foo" overrides "foo=..."
>       * 3) Old feature names with underscores (e.g. "sse4_2")
>       *    should keep working
>       *
> -     * Note: rules 1 and 2 are planned to be removed soon, and
> -     * should generate a warning.
> +     * Note: rule 2 is planned to be removed soon, and should generate
> +     * a warning.
>       */
>      qtest_start("-cpu pentium,-fpu,+fpu,-mce,mce=on,+cx8,cx8=off,+sse4_1,sse4_2=on");
>      path = get_cpu0_qom_path();
>  
> -    g_assert_false(qom_get_bool(path, "fpu"));
> +    g_assert_true(qom_get_bool(path, "fpu"));
>      g_assert_false(qom_get_bool(path, "mce"));
>      g_assert_true(qom_get_bool(path, "cx8"));
>  
> -- 
> 2.29.2
> 

-- 
Eduardo

Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[David Edmondson]

On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:

> Hi,
>
> Thanks for the patch.  Getting rid of special -feature/+feature
> behavior was in our TODO list for a long time.
>
> On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
>> "Minus" features are applied after "plus" features, so ensure that a
>> later "plus" feature causes an earlier "minus" feature to be removed.
>> 
>> This has no effect on the existing "-feature,feature=on" backward
>> compatibility code (which warns and turns the feature off).
>
> If we are changing behavior, why not change behavior of
> "-feature,feature=on" at the same time?  This would allow us to
> get rid of plus_features/minus_features completely and just make
> +feature/-feature synonyms to feature=on/feature=off.

Okay, I'll do that.

Given that there have been warnings associated with
"-feature,feature=on" for a while, changing that behaviour seems
acceptable.

Would the same be true for changing "-feature,+feature"? (i.e. what this
patch does) Really: can this just be changed, or does there have to be
some period where the behaviour stays the same with a warning?

>> 
>> Signed-off-by: David Edmondson <david.edmondson@oracle.com>
>> ---
>>  target/i386/cpu.c                   | 33 +++++++++++++++++++++++------
>>  tests/qtest/test-x86-cpuid-compat.c |  8 +++----
>>  2 files changed, 30 insertions(+), 11 deletions(-)
>> 
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 35459a38bb..13f58ef183 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -4750,13 +4750,32 @@ static void x86_cpu_parse_featurestr(const char *typename, char *features,
>>          GlobalProperty *prop;
>>  
>>          /* Compatibility syntax: */
>> -        if (featurestr[0] == '+') {
>> -            plus_features = g_list_append(plus_features,
>> -                                          g_strdup(featurestr + 1));
>> -            continue;
>> -        } else if (featurestr[0] == '-') {
>> -            minus_features = g_list_append(minus_features,
>> -                                           g_strdup(featurestr + 1));
>> +        if (featurestr[0] == '+' || featurestr[0] == '-') {
>> +            const char *feat = featurestr + 1;
>> +            GList **remove, **add;
>> +            GList *val;
>> +
>> +            if (featurestr[0] == '+') {
>> +                remove = &minus_features;
>> +                add = &plus_features;
>> +            } else {
>> +                remove = &plus_features;
>> +                add = &minus_features;
>> +            }
>> +
>> +            val = g_list_find_custom(*remove, feat, compare_string);
>> +            if (val) {
>> +                char *data = val->data;
>> +
>> +                *remove = g_list_remove(*remove, data);
>> +                g_free(data);
>> +            }
>> +
>> +            val = g_list_find_custom(*add, feat, compare_string);
>> +            if (!val) {
>> +                *add = g_list_append(*add, g_strdup(feat));
>> +            }
>
> I believe we'll be able to get rid of plus_features/minus_features
> completely if we remove compatibility of "-feature,feature=on".
> But if we don't, wouldn't it be simpler to replace
> plus_features/minus_features with a single list, appending items
> in the order they appear?

Will investigate.

>> +
>>              continue;
>>          }
>>  
>> diff --git a/tests/qtest/test-x86-cpuid-compat.c b/tests/qtest/test-x86-cpuid-compat.c
>> index 7ca1883a29..6824d2b13e 100644
>> --- a/tests/qtest/test-x86-cpuid-compat.c
>> +++ b/tests/qtest/test-x86-cpuid-compat.c
>> @@ -171,18 +171,18 @@ static void test_plus_minus_subprocess(void)
>>      char *path;
>>  
>>      /* Rules:
>> -     * 1)"-foo" overrides "+foo"
>> +     * 1) The later of "+foo" or "-foo" wins
>>       * 2) "[+-]foo" overrides "foo=..."
>>       * 3) Old feature names with underscores (e.g. "sse4_2")
>>       *    should keep working
>>       *
>> -     * Note: rules 1 and 2 are planned to be removed soon, and
>> -     * should generate a warning.
>> +     * Note: rule 2 is planned to be removed soon, and should generate
>> +     * a warning.
>>       */
>>      qtest_start("-cpu pentium,-fpu,+fpu,-mce,mce=on,+cx8,cx8=off,+sse4_1,sse4_2=on");
>>      path = get_cpu0_qom_path();
>>  
>> -    g_assert_false(qom_get_bool(path, "fpu"));
>> +    g_assert_true(qom_get_bool(path, "fpu"));
>>      g_assert_false(qom_get_bool(path, "mce"));
>>      g_assert_true(qom_get_bool(path, "cx8"));
>>  
>> -- 
>> 2.29.2
>> 
>
> -- 
> Eduardo

dme.
-- 
They must have taken my marbles away.

Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[Daniel P. Berrangé]

On Tue, Jan 19, 2021 at 02:22:05PM +0000, David Edmondson wrote:
> Currently "-cpu -feature,+feature" will disable -feature, which seems
> contrary to the intention of the user. Fix this such that the later
> flag wins. There are no changes to the interaction of +/- and =on/=off.

The -feature/+feature syntax is the legacy  way of configuring
features, with feature=on|off being the preferred, since that matches
the general QEMU standard for boolean properties.

Your proposed change in ordering of + vs - makes conceptual sense, but
it is none the less a semantic change in behaviour that may well cause
breakage for existing deployed VMs. This impacts guest ABI so could
particularly cause live migration problems.

IOW, we should have implemented it the way you propose in the first
place, but I don't think it is safe to change it now, unless you can
tie that new semantic to a machine type version.

Before we consider that though, Paolo has just deprecated many of the
legacy approaches for boolean properties in this:

  https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg04341.html

I'm inclined to say that we just follow on from that and finally
deprecate the +feature/-feature CPU syntax which we're already considering
legacy. This would remove the need to care about changing its behaviour


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Eduardo Habkost]

On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
> On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
> 
> > Hi,
> >
> > Thanks for the patch.  Getting rid of special -feature/+feature
> > behavior was in our TODO list for a long time.
> >
> > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
> >> "Minus" features are applied after "plus" features, so ensure that a
> >> later "plus" feature causes an earlier "minus" feature to be removed.
> >> 
> >> This has no effect on the existing "-feature,feature=on" backward
> >> compatibility code (which warns and turns the feature off).
> >
> > If we are changing behavior, why not change behavior of
> > "-feature,feature=on" at the same time?  This would allow us to
> > get rid of plus_features/minus_features completely and just make
> > +feature/-feature synonyms to feature=on/feature=off.
> 
> Okay, I'll do that.
> 
> Given that there have been warnings associated with
> "-feature,feature=on" for a while, changing that behaviour seems
> acceptable.
> 
> Would the same be true for changing "-feature,+feature"? (i.e. what this
> patch does) Really: can this just be changed, or does there have to be
> some period where the behaviour stays the same with a warning?

I actually expected warnings to be triggered when using
"-feature,+feature" as well.  If we were not generating warnings
for that case, it will need more careful evaluation, just to be
sure it's safe.  Igor, do you remember the details here?

-- 
Eduardo

Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[Eduardo Habkost]

On Tue, Jan 19, 2021 at 04:28:26PM +0000, Daniel P. Berrangé wrote:
> On Tue, Jan 19, 2021 at 02:22:05PM +0000, David Edmondson wrote:
> > Currently "-cpu -feature,+feature" will disable -feature, which seems
> > contrary to the intention of the user. Fix this such that the later
> > flag wins. There are no changes to the interaction of +/- and =on/=off.
> 
> The -feature/+feature syntax is the legacy  way of configuring
> features, with feature=on|off being the preferred, since that matches
> the general QEMU standard for boolean properties.
> 
> Your proposed change in ordering of + vs - makes conceptual sense, but
> it is none the less a semantic change in behaviour that may well cause
> breakage for existing deployed VMs. This impacts guest ABI so could
> particularly cause live migration problems.
> 
> IOW, we should have implemented it the way you propose in the first
> place, but I don't think it is safe to change it now, unless you can
> tie that new semantic to a machine type version.
> 
> Before we consider that though, Paolo has just deprecated many of the
> legacy approaches for boolean properties in this:
> 
>   https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg04341.html
> 
> I'm inclined to say that we just follow on from that and finally
> deprecate the +feature/-feature CPU syntax which we're already considering
> legacy. This would remove the need to care about changing its behaviour

I believe we had multiple proposal in the past do deprecate
+feature/-feature, but there were objections.  I couldn't find
the original threads, though.

In either case, I thought we had already deprecated the weird
ordering rules of "-feature,+feature".

-- 
Eduardo

Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[Daniel P. Berrangé]

On Tue, Jan 19, 2021 at 11:35:18AM -0500, Eduardo Habkost wrote:
> On Tue, Jan 19, 2021 at 04:28:26PM +0000, Daniel P. Berrangé wrote:
> > On Tue, Jan 19, 2021 at 02:22:05PM +0000, David Edmondson wrote:
> > > Currently "-cpu -feature,+feature" will disable -feature, which seems
> > > contrary to the intention of the user. Fix this such that the later
> > > flag wins. There are no changes to the interaction of +/- and =on/=off.
> > 
> > The -feature/+feature syntax is the legacy  way of configuring
> > features, with feature=on|off being the preferred, since that matches
> > the general QEMU standard for boolean properties.
> > 
> > Your proposed change in ordering of + vs - makes conceptual sense, but
> > it is none the less a semantic change in behaviour that may well cause
> > breakage for existing deployed VMs. This impacts guest ABI so could
> > particularly cause live migration problems.
> > 
> > IOW, we should have implemented it the way you propose in the first
> > place, but I don't think it is safe to change it now, unless you can
> > tie that new semantic to a machine type version.
> > 
> > Before we consider that though, Paolo has just deprecated many of the
> > legacy approaches for boolean properties in this:
> > 
> >   https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg04341.html
> > 
> > I'm inclined to say that we just follow on from that and finally
> > deprecate the +feature/-feature CPU syntax which we're already considering
> > legacy. This would remove the need to care about changing its behaviour
> 
> I believe we had multiple proposal in the past do deprecate
> +feature/-feature, but there were objections.  I couldn't find
> the original threads, though.

Historically libvirt was using +/- syntax, but we finally removed the last
usage of it in June 2019 / libvirt v5.4.0. So for modern QEMU libvirt will
always use =on|off.

> In either case, I thought we had already deprecated the weird
> ordering rules of "-feature,+feature".

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Igor Mammedov]

On Tue, 19 Jan 2021 11:30:52 -0500
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
> >   
> > > Hi,
> > >
> > > Thanks for the patch.  Getting rid of special -feature/+feature
> > > behavior was in our TODO list for a long time.
> > >
> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:  
> > >> "Minus" features are applied after "plus" features, so ensure that a
> > >> later "plus" feature causes an earlier "minus" feature to be removed.
> > >> 
> > >> This has no effect on the existing "-feature,feature=on" backward
> > >> compatibility code (which warns and turns the feature off).  
> > >
> > > If we are changing behavior, why not change behavior of
> > > "-feature,feature=on" at the same time?  This would allow us to
> > > get rid of plus_features/minus_features completely and just make
> > > +feature/-feature synonyms to feature=on/feature=off.  
> > 
> > Okay, I'll do that.
> > 
> > Given that there have been warnings associated with
> > "-feature,feature=on" for a while, changing that behaviour seems
> > acceptable.
> > 
> > Would the same be true for changing "-feature,+feature"? (i.e. what this
> > patch does) Really: can this just be changed, or does there have to be
> > some period where the behaviour stays the same with a warning?  
> 
> I actually expected warnings to be triggered when using
> "-feature,+feature" as well.  If we were not generating warnings
> for that case, it will need more careful evaluation, just to be
> sure it's safe.  Igor, do you remember the details here?
As part of preparation to define/create machines via QMP,
I plan to post patch(s) to deprecate +-features in 6.0
(including special casing for -feat behavior (affects x86/sparc only))
and drop support for +-feat in 2 releases.
So we should end up with canonical property behavior only like all other
CPUs and devices.

Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults

[Igor Mammedov]

On Tue, 19 Jan 2021 16:41:42 +0000
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Tue, Jan 19, 2021 at 11:35:18AM -0500, Eduardo Habkost wrote:
> > On Tue, Jan 19, 2021 at 04:28:26PM +0000, Daniel P. Berrangé wrote:  
> > > On Tue, Jan 19, 2021 at 02:22:05PM +0000, David Edmondson wrote:  
> > > > Currently "-cpu -feature,+feature" will disable -feature, which seems
> > > > contrary to the intention of the user. Fix this such that the later
> > > > flag wins. There are no changes to the interaction of +/- and =on/=off.  
> > > 
> > > The -feature/+feature syntax is the legacy  way of configuring
> > > features, with feature=on|off being the preferred, since that matches
> > > the general QEMU standard for boolean properties.
> > > 
> > > Your proposed change in ordering of + vs - makes conceptual sense, but
> > > it is none the less a semantic change in behaviour that may well cause
> > > breakage for existing deployed VMs. This impacts guest ABI so could
> > > particularly cause live migration problems.
> > > 
> > > IOW, we should have implemented it the way you propose in the first
> > > place, but I don't think it is safe to change it now, unless you can
> > > tie that new semantic to a machine type version.
> > > 
> > > Before we consider that though, Paolo has just deprecated many of the
> > > legacy approaches for boolean properties in this:
> > > 
> > >   https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg04341.html
> > > 
> > > I'm inclined to say that we just follow on from that and finally
> > > deprecate the +feature/-feature CPU syntax which we're already considering
> > > legacy. This would remove the need to care about changing its behaviour  
> > 
> > I believe we had multiple proposal in the past do deprecate
> > +feature/-feature, but there were objections.  I couldn't find
> > the original threads, though.  
> 
> Historically libvirt was using +/- syntax, but we finally removed the last
> usage of it in June 2019 / libvirt v5.4.0. So for modern QEMU libvirt will
> always use =on|off.
there are KVM unit tests that used /- syntax, I don't recall any attempt
to switch to canonical syntax.

> 
> > In either case, I thought we had already deprecated the weird
> > ordering rules of "-feature,+feature".  
> 
> Regards,
> Daniel

Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Daniel P. Berrangé]

On Tue, Jan 19, 2021 at 11:30:52AM -0500, Eduardo Habkost wrote:
> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
> > 
> > > Hi,
> > >
> > > Thanks for the patch.  Getting rid of special -feature/+feature
> > > behavior was in our TODO list for a long time.
> > >
> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
> > >> "Minus" features are applied after "plus" features, so ensure that a
> > >> later "plus" feature causes an earlier "minus" feature to be removed.
> > >> 
> > >> This has no effect on the existing "-feature,feature=on" backward
> > >> compatibility code (which warns and turns the feature off).
> > >
> > > If we are changing behavior, why not change behavior of
> > > "-feature,feature=on" at the same time?  This would allow us to
> > > get rid of plus_features/minus_features completely and just make
> > > +feature/-feature synonyms to feature=on/feature=off.
> > 
> > Okay, I'll do that.
> > 
> > Given that there have been warnings associated with
> > "-feature,feature=on" for a while, changing that behaviour seems
> > acceptable.
> > 
> > Would the same be true for changing "-feature,+feature"? (i.e. what this
> > patch does) Really: can this just be changed, or does there have to be
> > some period where the behaviour stays the same with a warning?
> 
> I actually expected warnings to be triggered when using
> "-feature,+feature" as well.  If we were not generating warnings
> for that case, it will need more careful evaluation, just to be
> sure it's safe.  Igor, do you remember the details here?

Where are you expecting warnings ? I don't see any when launching QEMU

$ qemu-system-x86_64 -display none  -cpu Westmere,-vmx 

$ qemu-system-x86_64 -display none  -cpu Westmere,-vmx,sse=on

neither produces warnings, even with current git master.

I don't think we can change the parsing behaviour here without impacting
guest ABI, and that feels dangerous given that we've not been warning
people the syntax is undesirable.

IMHO just leave the parsing unchanged, deprecate it, and then delete
the code.  We don't need to "improve" usability semantics of something
that we want to delete anyway.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[David Edmondson]

On Wednesday, 2021-01-20 at 10:59:24 +01, Igor Mammedov wrote:

> On Tue, 19 Jan 2021 11:30:52 -0500
> Eduardo Habkost <ehabkost@redhat.com> wrote:
>
>> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
>> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
>> >   
>> > > Hi,
>> > >
>> > > Thanks for the patch.  Getting rid of special -feature/+feature
>> > > behavior was in our TODO list for a long time.
>> > >
>> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:  
>> > >> "Minus" features are applied after "plus" features, so ensure that a
>> > >> later "plus" feature causes an earlier "minus" feature to be removed.
>> > >> 
>> > >> This has no effect on the existing "-feature,feature=on" backward
>> > >> compatibility code (which warns and turns the feature off).  
>> > >
>> > > If we are changing behavior, why not change behavior of
>> > > "-feature,feature=on" at the same time?  This would allow us to
>> > > get rid of plus_features/minus_features completely and just make
>> > > +feature/-feature synonyms to feature=on/feature=off.  
>> > 
>> > Okay, I'll do that.
>> > 
>> > Given that there have been warnings associated with
>> > "-feature,feature=on" for a while, changing that behaviour seems
>> > acceptable.
>> > 
>> > Would the same be true for changing "-feature,+feature"? (i.e. what this
>> > patch does) Really: can this just be changed, or does there have to be
>> > some period where the behaviour stays the same with a warning?  
>> 
>> I actually expected warnings to be triggered when using
>> "-feature,+feature" as well.  If we were not generating warnings
>> for that case, it will need more careful evaluation, just to be
>> sure it's safe.  Igor, do you remember the details here?
> As part of preparation to define/create machines via QMP,
> I plan to post patch(s) to deprecate +-features in 6.0
> (including special casing for -feat behavior (affects x86/sparc only))
> and drop support for +-feat in 2 releases.
> So we should end up with canonical property behavior only like all other
> CPUs and devices.

In that case I will abandon this change and focus on getting my upstack
consumer to switch away from using +-.

Thanks.

dme.
-- 
Sometimes these eyes, forget the face they're peering from.

Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[David Edmondson]

On Wednesday, 2021-01-20 at 10:08:03 GMT, Daniel P. Berrangé wrote:

> On Tue, Jan 19, 2021 at 11:30:52AM -0500, Eduardo Habkost wrote:
>> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
>> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
>> > 
>> > > Hi,
>> > >
>> > > Thanks for the patch.  Getting rid of special -feature/+feature
>> > > behavior was in our TODO list for a long time.
>> > >
>> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
>> > >> "Minus" features are applied after "plus" features, so ensure that a
>> > >> later "plus" feature causes an earlier "minus" feature to be removed.
>> > >> 
>> > >> This has no effect on the existing "-feature,feature=on" backward
>> > >> compatibility code (which warns and turns the feature off).
>> > >
>> > > If we are changing behavior, why not change behavior of
>> > > "-feature,feature=on" at the same time?  This would allow us to
>> > > get rid of plus_features/minus_features completely and just make
>> > > +feature/-feature synonyms to feature=on/feature=off.
>> > 
>> > Okay, I'll do that.
>> > 
>> > Given that there have been warnings associated with
>> > "-feature,feature=on" for a while, changing that behaviour seems
>> > acceptable.
>> > 
>> > Would the same be true for changing "-feature,+feature"? (i.e. what this
>> > patch does) Really: can this just be changed, or does there have to be
>> > some period where the behaviour stays the same with a warning?
>> 
>> I actually expected warnings to be triggered when using
>> "-feature,+feature" as well.  If we were not generating warnings
>> for that case, it will need more careful evaluation, just to be
>> sure it's safe.  Igor, do you remember the details here?
>
> Where are you expecting warnings ? I don't see any when launching QEMU

qemu-system-x86_64 -display none -cpu Westmere,-vmx,+vmx

Warnings because the result of this is "-vmx".

> IMHO just leave the parsing unchanged, deprecate it, and then delete
> the code.  We don't need to "improve" usability semantics of something
> that we want to delete anyway.

/me nods.

dme.
-- 
I just bite it, it's for the look I don't light it.

Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Eduardo Habkost]

On Wed, Jan 20, 2021 at 10:17:36AM +0000, David Edmondson wrote:
> On Wednesday, 2021-01-20 at 10:08:03 GMT, Daniel P. Berrangé wrote:
> 
> > On Tue, Jan 19, 2021 at 11:30:52AM -0500, Eduardo Habkost wrote:
> >> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:
> >> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
> >> > 
> >> > > Hi,
> >> > >
> >> > > Thanks for the patch.  Getting rid of special -feature/+feature
> >> > > behavior was in our TODO list for a long time.
> >> > >
> >> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:
> >> > >> "Minus" features are applied after "plus" features, so ensure that a
> >> > >> later "plus" feature causes an earlier "minus" feature to be removed.
> >> > >> 
> >> > >> This has no effect on the existing "-feature,feature=on" backward
> >> > >> compatibility code (which warns and turns the feature off).
> >> > >
> >> > > If we are changing behavior, why not change behavior of
> >> > > "-feature,feature=on" at the same time?  This would allow us to
> >> > > get rid of plus_features/minus_features completely and just make
> >> > > +feature/-feature synonyms to feature=on/feature=off.
> >> > 
> >> > Okay, I'll do that.
> >> > 
> >> > Given that there have been warnings associated with
> >> > "-feature,feature=on" for a while, changing that behaviour seems
> >> > acceptable.
> >> > 
> >> > Would the same be true for changing "-feature,+feature"? (i.e. what this
> >> > patch does) Really: can this just be changed, or does there have to be
> >> > some period where the behaviour stays the same with a warning?
> >> 
> >> I actually expected warnings to be triggered when using
> >> "-feature,+feature" as well.  If we were not generating warnings
> >> for that case, it will need more careful evaluation, just to be
> >> sure it's safe.  Igor, do you remember the details here?
> >
> > Where are you expecting warnings ? I don't see any when launching QEMU
> 
> qemu-system-x86_64 -display none -cpu Westmere,-vmx,+vmx
> 
> Warnings because the result of this is "-vmx".
> 
> > IMHO just leave the parsing unchanged, deprecate it, and then delete
> > the code.  We don't need to "improve" usability semantics of something
> > that we want to delete anyway.
> 
> /me nods.

I agree, but I guess we need to convince Paolo:
https://lore.kernel.org/qemu-devel/1990888058.22417362.1465939000140.JavaMail.zimbra@redhat.com/

-- 
Eduardo

Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature

[Igor Mammedov]

On Wed, 20 Jan 2021 11:18:01 -0500
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Wed, Jan 20, 2021 at 10:17:36AM +0000, David Edmondson wrote:
> > On Wednesday, 2021-01-20 at 10:08:03 GMT, Daniel P. Berrangé wrote:
> >   
> > > On Tue, Jan 19, 2021 at 11:30:52AM -0500, Eduardo Habkost wrote:  
> > >> On Tue, Jan 19, 2021 at 04:27:56PM +0000, David Edmondson wrote:  
> > >> > On Tuesday, 2021-01-19 at 10:20:56 -05, Eduardo Habkost wrote:
> > >> >   
> > >> > > Hi,
> > >> > >
> > >> > > Thanks for the patch.  Getting rid of special -feature/+feature
> > >> > > behavior was in our TODO list for a long time.
> > >> > >
> > >> > > On Tue, Jan 19, 2021 at 02:22:06PM +0000, David Edmondson wrote:  
> > >> > >> "Minus" features are applied after "plus" features, so ensure that a
> > >> > >> later "plus" feature causes an earlier "minus" feature to be removed.
> > >> > >> 
> > >> > >> This has no effect on the existing "-feature,feature=on" backward
> > >> > >> compatibility code (which warns and turns the feature off).  
> > >> > >
> > >> > > If we are changing behavior, why not change behavior of
> > >> > > "-feature,feature=on" at the same time?  This would allow us to
> > >> > > get rid of plus_features/minus_features completely and just make
> > >> > > +feature/-feature synonyms to feature=on/feature=off.  
> > >> > 
> > >> > Okay, I'll do that.
> > >> > 
> > >> > Given that there have been warnings associated with
> > >> > "-feature,feature=on" for a while, changing that behaviour seems
> > >> > acceptable.
> > >> > 
> > >> > Would the same be true for changing "-feature,+feature"? (i.e. what this
> > >> > patch does) Really: can this just be changed, or does there have to be
> > >> > some period where the behaviour stays the same with a warning?  
> > >> 
> > >> I actually expected warnings to be triggered when using
> > >> "-feature,+feature" as well.  If we were not generating warnings
> > >> for that case, it will need more careful evaluation, just to be
> > >> sure it's safe.  Igor, do you remember the details here?  
> > >
> > > Where are you expecting warnings ? I don't see any when launching QEMU  
> > 
> > qemu-system-x86_64 -display none -cpu Westmere,-vmx,+vmx
> > 
> > Warnings because the result of this is "-vmx".
> >   
> > > IMHO just leave the parsing unchanged, deprecate it, and then delete
> > > the code.  We don't need to "improve" usability semantics of something
> > > that we want to delete anyway.  
> > 
> > /me nods.  
> 
> I agree, but I guess we need to convince Paolo:
> https://lore.kernel.org/qemu-devel/1990888058.22417362.1465939000140.JavaMail.zimbra@redhat.com/
that's ancient :)

He recently started this revolution himself :)
https://www.mail-archive.com/qemu-devel@nongnu.org/msg757280.html

That's why I have -cpu +/-foo deprecation on my not too far away TODO list.

[PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax

[Eduardo Habkost]

The ordering semantics of +feature/-feature is tricky and not
obvious, and it requires a custom option parser.  Deprecate that
syntax so we can eventually remove the custom -cpu option parser
and plus_features/minus_features global variables in i386.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 docs/system/deprecated.rst | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index e20bfcb17a4..2c4b8d4b78b 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -127,6 +127,20 @@ Drives with interface types other than ``if=none`` are for onboard
 devices.  It is possible to use drives the board doesn't pick up with
 -device.  This usage is now deprecated.  Use ``if=none`` instead.
 
+``-cpu`` ``+feature`` and ``-feature`` syntax (since 6.0.0)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The ``-cpu ...,+feature`` and ``-cpu ...,-feature`` syntax for
+enabling and disabling CPU features is deprecated.  The ``-cpu
+...,feature=on`` or ``-cpu ...,feature=off`` should be used
+instead.
+
+Note that the ordering semantics of ``-cpu ...,-feature,+feature``
+is different from ``-cpu ...,feature=off,feature=on``.  With the
+former, the feature got disabled because ``-feature`` had
+precedence, but with the latter the feature will be enabled
+because options are applied in the order they appear.
+
 
 QEMU Machine Protocol (QMP) commands
 ------------------------------------
-- 
2.28.0

Re: [PATCH] docs/system: Deprecate `-cpu ..., +feature, -feature` syntax

[David Edmondson]

On Wednesday, 2021-01-20 at 15:12:41 -05, Eduardo Habkost wrote:

> The ordering semantics of +feature/-feature is tricky and not
> obvious, and it requires a custom option parser.  Deprecate that
> syntax so we can eventually remove the custom -cpu option parser
> and plus_features/minus_features global variables in i386.
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

With very minor wording comment...

Reviewed-by: David Edmondson <david.edmondson@oracle.com>

> ---
>  docs/system/deprecated.rst | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index e20bfcb17a4..2c4b8d4b78b 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -127,6 +127,20 @@ Drives with interface types other than ``if=none`` are for onboard
>  devices.  It is possible to use drives the board doesn't pick up with
>  -device.  This usage is now deprecated.  Use ``if=none`` instead.
>  
> +``-cpu`` ``+feature`` and ``-feature`` syntax (since 6.0.0)
> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The ``-cpu ...,+feature`` and ``-cpu ...,-feature`` syntax for
> +enabling and disabling CPU features is deprecated.  The ``-cpu
> +...,feature=on`` or ``-cpu ...,feature=off`` should be used
> +instead.
> +
> +Note that the ordering semantics of ``-cpu ...,-feature,+feature``
> +is different from ``-cpu ...,feature=off,feature=on``.  With the
> +former, the feature got disabled because ``-feature`` had

s/got/was/

> +precedence, but with the latter the feature will be enabled
> +because options are applied in the order they appear.
> +
>  
>  QEMU Machine Protocol (QMP) commands
>  ------------------------------------
> -- 
> 2.28.0

dme.
-- 
I got a girlfriend that's better than that.

Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax

[Daniel P. Berrangé]

On Wed, Jan 20, 2021 at 03:12:41PM -0500, Eduardo Habkost wrote:
> The ordering semantics of +feature/-feature is tricky and not
> obvious, and it requires a custom option parser.  Deprecate that
> syntax so we can eventually remove the custom -cpu option parser
> and plus_features/minus_features global variables in i386.
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  docs/system/deprecated.rst | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)

Ideally we would also print a warning on stderr when this deprecated
style is used.

> 
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index e20bfcb17a4..2c4b8d4b78b 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -127,6 +127,20 @@ Drives with interface types other than ``if=none`` are for onboard
>  devices.  It is possible to use drives the board doesn't pick up with
>  -device.  This usage is now deprecated.  Use ``if=none`` instead.
>  
> +``-cpu`` ``+feature`` and ``-feature`` syntax (since 6.0.0)
> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The ``-cpu ...,+feature`` and ``-cpu ...,-feature`` syntax for
> +enabling and disabling CPU features is deprecated.  The ``-cpu
> +...,feature=on`` or ``-cpu ...,feature=off`` should be used
> +instead.
> +
> +Note that the ordering semantics of ``-cpu ...,-feature,+feature``
> +is different from ``-cpu ...,feature=off,feature=on``.  With the
> +former, the feature got disabled because ``-feature`` had
> +precedence, but with the latter the feature will be enabled
> +because options are applied in the order they appear.
> +

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax

[Igor Mammedov]

On Wed, 20 Jan 2021 15:12:41 -0500
Eduardo Habkost <ehabkost@redhat.com> wrote:

> The ordering semantics of +feature/-feature is tricky and not
> obvious, and it requires a custom option parser.  Deprecate that
> syntax so we can eventually remove the custom -cpu option parser
> and plus_features/minus_features global variables in i386.
it affects spark as well

with that

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  docs/system/deprecated.rst | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index e20bfcb17a4..2c4b8d4b78b 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -127,6 +127,20 @@ Drives with interface types other than ``if=none`` are for onboard
>  devices.  It is possible to use drives the board doesn't pick up with
>  -device.  This usage is now deprecated.  Use ``if=none`` instead.
>  
> +``-cpu`` ``+feature`` and ``-feature`` syntax (since 6.0.0)
> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The ``-cpu ...,+feature`` and ``-cpu ...,-feature`` syntax for
> +enabling and disabling CPU features is deprecated.  The ``-cpu
> +...,feature=on`` or ``-cpu ...,feature=off`` should be used
> +instead.
> +
> +Note that the ordering semantics of ``-cpu ...,-feature,+feature``
> +is different from ``-cpu ...,feature=off,feature=on``.  With the
> +former, the feature got disabled because ``-feature`` had
> +precedence, but with the latter the feature will be enabled
> +because options are applied in the order they appear.
> +
>  
>  QEMU Machine Protocol (QMP) commands
>  ------------------------------------

Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax

[John Snow]

On 1/21/21 4:39 AM, Daniel P. Berrangé wrote:
> On Wed, Jan 20, 2021 at 03:12:41PM -0500, Eduardo Habkost wrote:
>> The ordering semantics of +feature/-feature is tricky and not
>> obvious, and it requires a custom option parser.  Deprecate that
>> syntax so we can eventually remove the custom -cpu option parser
>> and plus_features/minus_features global variables in i386.
>>
>> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>> ---
>>   docs/system/deprecated.rst | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
> 
> Ideally we would also print a warning on stderr when this deprecated
> style is used.
> 

+1.

It might break some tests to do that, though, but if it's not too 
gruesome it's probably worth it.