Added an updated summary for the reasons, now starting the tests on how much (or not) of a corner case that will most likely be.
Note: I also pinged the openstack Team to check their configs if it would be an issue for them. Subscribed jamespage and coreycb here now as well. ** Description changed: There seem to be conditions where old qemu/libvirt created guests with the osxsafe feature <model fallback='allow'>Broadwell-noTSX</model> <vendor>Intel</vendor> ... <feature policy='require' name='osxsave'/> That feature was now removed in recent qemu. => https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522 - But its lack might cause issues starting some old guests using it after upgrade. qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64-cpu.osxsave=on: Property '.osxsave' not found Same bug in Fedora: => https://bugzilla.redhat.com/show_bug.cgi?id=1644848 - I'd want to analyze omre of the background, why we have it in our IBRS - type (still it seems) and if we can make modifications to make the - transition more smooth. + + Both commandline arg drops "osxsave" / "ospke" were effective no-ops as it was - quote: "never configurable: KVM never returned OSXSAVE on GET_SUPPORTED_CPUID". See removal commits [1][2]. + + Discussions went on if this should be warnings instead of errors for a + while (the deprecation discussion is ongoing anyway). But for now we are + in the situation that calling qemu with those features makes it fail to + start. I'd not want to derive from upstream qemu and the discussion on + depreceation - as mentioned - is a longer one that won't resolve too + soon - a.k.a we can't wait on that. + + The discussion at [3] reached no conclusion and was forgotten. I checked + with Jiri and there was no follow on. + + But since specifying the features never meant anything to qemu we should at least consider libvirt to learn about that and just not specify the flags. + If there is a good place for a warning we might emit one if required was set, but this is not strictly required at first. + + [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7 + [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc + [3]: https://www.mail-archive.com/[email protected]/msg561877.html ** Description changed: - There seem to be conditions where old qemu/libvirt created guests with - the osxsafe feature + ## Bug ## - <model fallback='allow'>Broadwell-noTSX</model> - <vendor>Intel</vendor> - ... + There are conditions where old qemu/libvirt created guests with the + osxsafe cpu feature: + <feature policy='require' name='osxsave'/> - That feature was now removed in recent qemu. - => https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522 + That feature was removed in recent qemu, this triggers issues starting + some old guests definitions using it after upgrade. - But its lack might cause issues starting some old guests using it after upgrade. - qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64-cpu.osxsave=on: Property '.osxsave' not found + qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64- + cpu.osxsave=on: Property '.osxsave' not found - Same bug in Fedora: + Same bug in Fedora (incomplete): => https://bugzilla.redhat.com/show_bug.cgi?id=1644848 + ## What happened ## - Both commandline arg drops "osxsave" / "ospke" were effective no-ops as it was - quote: "never configurable: KVM never returned OSXSAVE on GET_SUPPORTED_CPUID". See removal commits [1][2]. + Both commandline arg drops "osxsave" / "ospke" were effective no-ops as + it was - quote: "never configurable: KVM never returned OSXSAVE on + GET_SUPPORTED_CPUID". See removal commits [1][2]. Discussions went on if this should be warnings instead of errors for a while (the deprecation discussion is ongoing anyway). But for now we are in the situation that calling qemu with those features makes it fail to start. I'd not want to derive from upstream qemu and the discussion on depreceation - as mentioned - is a longer one that won't resolve too soon - a.k.a we can't wait on that. The discussion at [3] reached no conclusion and was forgotten. I checked with Jiri and there was no follow on. But since specifying the features never meant anything to qemu we should at least consider libvirt to learn about that and just not specify the flags. If there is a good place for a warning we might emit one if required was set, but this is not strictly required at first. [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7 [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc [3]: https://www.mail-archive.com/[email protected]/msg561877.html ** Description changed: ## Bug ## There are conditions where old qemu/libvirt created guests with the - osxsafe cpu feature: + osxsafe or ospke cpu feature: <feature policy='require' name='osxsave'/> + <feature policy='require' name='ospke'/> That feature was removed in recent qemu, this triggers issues starting some old guests definitions using it after upgrade. qemu-system-x86_64: can't apply global Broadwell-noTSX-x86_64- - cpu.osxsave=on: Property '.osxsave' not found + cpu.osxsave=on: Property '.osxsave' not found Same bug in Fedora (incomplete): => https://bugzilla.redhat.com/show_bug.cgi?id=1644848 ## What happened ## Both commandline arg drops "osxsave" / "ospke" were effective no-ops as it was - quote: "never configurable: KVM never returned OSXSAVE on GET_SUPPORTED_CPUID". See removal commits [1][2]. Discussions went on if this should be warnings instead of errors for a while (the deprecation discussion is ongoing anyway). But for now we are in the situation that calling qemu with those features makes it fail to start. I'd not want to derive from upstream qemu and the discussion on depreceation - as mentioned - is a longer one that won't resolve too soon - a.k.a we can't wait on that. The discussion at [3] reached no conclusion and was forgotten. I checked with Jiri and there was no follow on. But since specifying the features never meant anything to qemu we should at least consider libvirt to learn about that and just not specify the flags. If there is a good place for a warning we might emit one if required was set, but this is not strictly required at first. [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7 [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc [3]: https://www.mail-archive.com/[email protected]/msg561877.html ** Summary changed: - qemu lost osxsave feature bit (ok) which might cause upgrade issues (not so ok) + qemu dropped osxsave/ospke feature triggering upgrade issues -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1825195 Title: qemu dropped osxsave/ospke feature triggering upgrade issues To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
