* [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults @ 2021-01-19 14:22 David Edmondson 2021-01-19 14:22 ` [RFC PATCH 1/2] hw/i386: -cpu model, -feature, +feature should enable feature David Edmondson ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: David Edmondson @ 2021-01-19 14:22 UTC (permalink / raw) To: qemu-devel Cc: Laurent Vivier, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin, Richard Henderson, David Edmondson, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [RFC PATCH 1/2] hw/i386: -cpu model, -feature, +feature should enable feature 2021-01-19 14:22 [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults David Edmondson @ 2021-01-19 14:22 ` David Edmondson 2021-01-19 15:20 ` [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature " Eduardo Habkost 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é 2 siblings, 1 reply; 21+ messages in thread From: David Edmondson @ 2021-01-19 14:22 UTC (permalink / raw) To: qemu-devel Cc: Laurent Vivier, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin, Richard Henderson, David Edmondson, Paolo Bonzini "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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 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 ` Eduardo Habkost 2021-01-19 16:27 ` [External] : " David Edmondson 0 siblings, 1 reply; 21+ messages in thread From: Eduardo Habkost @ 2021-01-19 15:20 UTC (permalink / raw) To: David Edmondson Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-19 15:20 ` [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature " Eduardo Habkost @ 2021-01-19 16:27 ` David Edmondson 2021-01-19 16:30 ` Eduardo Habkost 0 siblings, 1 reply; 21+ messages in thread From: David Edmondson @ 2021-01-19 16:27 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-19 16:27 ` [External] : " David Edmondson @ 2021-01-19 16:30 ` Eduardo Habkost 2021-01-20 9:59 ` Igor Mammedov 2021-01-20 10:08 ` [External] : " Daniel P. Berrangé 0 siblings, 2 replies; 21+ messages in thread From: Eduardo Habkost @ 2021-01-19 16:30 UTC (permalink / raw) To: David Edmondson Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-19 16:30 ` 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é 1 sibling, 1 reply; 21+ messages in thread From: Igor Mammedov @ 2021-01-20 9:59 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, David Edmondson, Richard Henderson, qemu-devel, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-20 9:59 ` Igor Mammedov @ 2021-01-20 10:08 ` David Edmondson 0 siblings, 0 replies; 21+ messages in thread From: David Edmondson @ 2021-01-20 10:08 UTC (permalink / raw) To: Igor Mammedov, Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [External] : Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-19 16:30 ` Eduardo Habkost 2021-01-20 9:59 ` Igor Mammedov @ 2021-01-20 10:08 ` Daniel P. Berrangé 2021-01-20 10:17 ` David Edmondson 1 sibling, 1 reply; 21+ messages in thread From: Daniel P. Berrangé @ 2021-01-20 10:08 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, David Edmondson, Richard Henderson, qemu-devel, Paolo Bonzini, Igor Mammedov 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 :| ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-20 10:08 ` [External] : " Daniel P. Berrangé @ 2021-01-20 10:17 ` David Edmondson 2021-01-20 16:18 ` Eduardo Habkost 0 siblings, 1 reply; 21+ messages in thread From: David Edmondson @ 2021-01-20 10:17 UTC (permalink / raw) To: Daniel P. Berrangé, Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 2021-01-20 10:17 ` David Edmondson @ 2021-01-20 16:18 ` Eduardo Habkost 2021-01-20 19:21 ` Igor Mammedov 0 siblings, 1 reply; 21+ messages in thread From: Eduardo Habkost @ 2021-01-20 16:18 UTC (permalink / raw) To: David Edmondson Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 1/2] hw/i386: -cpu model,-feature,+feature should enable feature 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 0 siblings, 1 reply; 21+ messages in thread From: Igor Mammedov @ 2021-01-20 19:21 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, Michael S. Tsirkin, David Edmondson, Richard Henderson, qemu-devel, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax 2021-01-20 19:21 ` Igor Mammedov @ 2021-01-20 20:12 ` Eduardo Habkost 2021-01-20 20:19 ` [PATCH] docs/system: Deprecate `-cpu ..., +feature, -feature` syntax David Edmondson ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Eduardo Habkost @ 2021-01-20 20:12 UTC (permalink / raw) To: qemu-devel Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, Michael S. Tsirkin, David Edmondson, Richard Henderson, qemu-devel, Paolo Bonzini, Igor Mammedov 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] docs/system: Deprecate `-cpu ..., +feature, -feature` syntax 2021-01-20 20:12 ` [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax Eduardo Habkost @ 2021-01-20 20:19 ` David Edmondson 2021-01-21 9:39 ` [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax Daniel P. Berrangé 2021-01-21 10:25 ` Igor Mammedov 2 siblings, 0 replies; 21+ messages in thread From: David Edmondson @ 2021-01-20 20:19 UTC (permalink / raw) To: Eduardo Habkost, qemu-devel Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax 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 ` Daniel P. Berrangé 2021-01-27 0:14 ` John Snow 2021-01-21 10:25 ` Igor Mammedov 2 siblings, 1 reply; 21+ messages in thread From: Daniel P. Berrangé @ 2021-01-21 9:39 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, David Edmondson, Richard Henderson, qemu-devel, Paolo Bonzini, Igor Mammedov 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 :| ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax 2021-01-21 9:39 ` [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax Daniel P. Berrangé @ 2021-01-27 0:14 ` John Snow 0 siblings, 0 replies; 21+ messages in thread From: John Snow @ 2021-01-27 0:14 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, David Edmondson, Michael S. Tsirkin, Richard Henderson, qemu-devel, Igor Mammedov, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] docs/system: Deprecate `-cpu ...,+feature,-feature` syntax 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-21 10:25 ` Igor Mammedov 2 siblings, 0 replies; 21+ messages in thread From: Igor Mammedov @ 2021-01-21 10:25 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Daniel P. Berrangé, David Edmondson, Michael S. Tsirkin, Richard Henderson, qemu-devel, Paolo Bonzini 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 > ------------------------------------ ^ permalink raw reply [flat|nested] 21+ messages in thread
* [RFC PATCH 2/2] target/i386: Add "-cpu +kvm-no-defaults" 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 14:22 ` David Edmondson 2021-01-19 16:28 ` [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults Daniel P. Berrangé 2 siblings, 0 replies; 21+ messages in thread From: David Edmondson @ 2021-01-19 14:22 UTC (permalink / raw) To: qemu-devel Cc: Laurent Vivier, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin, Richard Henderson, David Edmondson, Paolo Bonzini, Joao Martins 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 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults 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 14:22 ` [RFC PATCH 2/2] target/i386: Add "-cpu +kvm-no-defaults" David Edmondson @ 2021-01-19 16:28 ` Daniel P. Berrangé 2021-01-19 16:35 ` Eduardo Habkost 2 siblings, 1 reply; 21+ messages in thread From: Daniel P. Berrangé @ 2021-01-19 16:28 UTC (permalink / raw) To: David Edmondson Cc: Laurent Vivier, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin, Richard Henderson, qemu-devel, Markus Armbruster, Paolo Bonzini 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 :| ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults 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é 0 siblings, 1 reply; 21+ messages in thread From: Eduardo Habkost @ 2021-01-19 16:35 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Markus Armbruster, David Edmondson, Igor Mammedov, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults 2021-01-19 16:35 ` Eduardo Habkost @ 2021-01-19 16:41 ` Daniel P. Berrangé 2021-01-20 10:01 ` Igor Mammedov 0 siblings, 1 reply; 21+ messages in thread From: Daniel P. Berrangé @ 2021-01-19 16:41 UTC (permalink / raw) To: Eduardo Habkost Cc: Laurent Vivier, Thomas Huth, Michael S. Tsirkin, Richard Henderson, qemu-devel, Markus Armbruster, David Edmondson, Igor Mammedov, Paolo Bonzini 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 :| ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [RFC PATCH 0/2] x86 CPU feature +/- fiddling and +kvm-no-defaults 2021-01-19 16:41 ` Daniel P. Berrangé @ 2021-01-20 10:01 ` Igor Mammedov 0 siblings, 0 replies; 21+ messages in thread From: Igor Mammedov @ 2021-01-20 10:01 UTC (permalink / raw) To: Daniel P. Berrangé Cc: Laurent Vivier, Thomas Huth, Eduardo Habkost, Michael S. Tsirkin, Richard Henderson, qemu-devel, Markus Armbruster, David Edmondson, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-01-27 0:16 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` [External] : " David Edmondson 2021-01-19 16:30 ` 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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.