| Message ID | 20210119142207.3443123-1-david.edmondson@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86 CPU feature +/- fiddling and +kvm-no-defaults | expand |
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
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".
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
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