From: David Edmondson <dme@dme.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature
Date: Tue, 19 Jan 2021 16:27:56 +0000 [thread overview]
Message-ID: <cuna6t499ir.fsf@dme.org> (raw)
In-Reply-To: <20210119152056.GE1227584@habkost.net>
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.
next prev parent reply other threads:[~2021-01-19 18:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-19 14:22 [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults David Edmondson
2021-01-19 14:22 ` [RFC PATCH 1/2] hw/i386: -cpu model, -feature, +feature should enable feature David Edmondson
2021-01-19 15:20 ` [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature " Eduardo Habkost
2021-01-19 16:27 ` David Edmondson [this message]
2021-01-19 16:30 ` [External] : " Eduardo Habkost
2021-01-20 9:59 ` Igor Mammedov
2021-01-20 10:08 ` David Edmondson
2021-01-20 10:08 ` [External] : " Daniel P. Berrangé
2021-01-20 10:17 ` David Edmondson
2021-01-20 16:18 ` Eduardo Habkost
2021-01-20 19:21 ` Igor Mammedov
2021-01-20 20:12 ` [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax Eduardo Habkost
2021-01-20 20:19 ` [PATCH] docs/system: Deprecate `-cpu ..., +feature, -feature` syntax David Edmondson
2021-01-21 9:39 ` [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax Daniel P. Berrangé
2021-01-27 0:14 ` John Snow
2021-01-21 10:25 ` Igor Mammedov
2021-01-19 14:22 ` [RFC PATCH 2/2] target/i386: Add "-cpu +kvm-no-defaults" David Edmondson
2021-01-19 16:28 ` [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults Daniel P. Berrangé
2021-01-19 16:35 ` Eduardo Habkost
2021-01-19 16:41 ` Daniel P. Berrangé
2021-01-20 10:01 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cuna6t499ir.fsf@dme.org \
--to=dme@dme.org \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).