Re: [libvirt] [PATCH 0/2] Avoid issues due to qemu dropping osxsave and ospke

On Tue, May 7, 2019 at 11:03 PM Daniel Henrique Barboza <danielhb413(a)gmail.com&gt; wrote: > > > On 4/25/19 9:50 AM, Christian Ehrhardt wrote: >> Hi, >> this series tries to address a drop of commandline options by qemu in regard to >> osxsave [1] and ospke [2]. >> This was already discussed in [3] late last year but got forgotten afterwards. >> The Ubuntu bug is at [4] and an older Fedora bug is at [5]. >> >> TL;DR: >> - osxsave/ospke features were never really configurable >> - KVM never returned the bits on GET_SUPPORTED_CPUID >> - very rare to be seen in the wild >> - avoid issues with newer qemu and old/odd XMLs to be sure >> >> Details: >> >> I checked various use cases from virt-install to openstack and some in between. >> The only cases I found that would define osxsave/ospke is virt-install pior >> to version 2.0 and even there only when used with --cpu=host-model or >> --cpu=host-copy. >> If you ever really enabled the feature you'd have got: >> error: the CPU is incompatible with host CPU: >> Host CPU does not provide required features: ospke >> >> The problem lies in domain XMLs that explicitly disable it. That would be >> <feature policy='disable' name='osxsave'/> >> But due to almost (or actually none) no host exposing this the following >> also triggers: >> <feature policy='optional' name='ospke'/> > So, it happened that this notebook (ThinkPad T480) has the feature you're > handling in this patch series: Mine as well actually, but obviously only on the host capabilities. [...]

> With your approach, what happens is that a feature that is declared to be > effective in the capabilities is, in fact, ignored. It is an upgrade of > what would happen without it, of course. Some bikeshedding on "declared to be effective in the capabilities" needed to bring me up to date on this. See below... > But I am wondering here, fully aware that you mentioned that you wanted this > discussion to be avoided, Sorry my comment was misleading then - I'm absolutely fine having that part of the discussion in this context. I only wanted to avoid the discussion about removing features that "actually did something" which naturally is a way more complex topic. > that we should simply exterminate both osxsave and > ospke from Libvirt capabilities. I mean, what's the point of even > reporting them > if they will end up being ignored? You have both QEMU commits [1] and [2] > mentioning that these flags were never configurable in the first place, > so it's not > like we need to keep them for backward compatibility either. Maybe it is my current lack of understanding how "exterminating both" would be exactly done and I see potential issues where there are none. I wonder would that just be dropping the mappings in src/cpu_map/x86_features.xml? If not then I'd appreciate a hint where exactly you'd suggest we would do the mentioned further extermination of ospke/osxsave. I was afraid of side effects or when no more being detected. And even more so it seems the definition of "capabilities" is not clear enough to me (I never thought too much about it so far): - "The capabilities of the hypervisor" (man page) - "The host CPU architecture and features." (web page) For the former definition yes, we might want to drop such non passable features then. But for the latter definition it feels right to continue reporting that the host has it. It is valid to report that the host has the feature - even thou it can't pass it to a guest. After all it is in the host and not the guest (hypervisor dependent) section of capabilities right?

Also we might (later) use the mapping for other things down the road where being an tunable feature (or not) is not important either. Or users compare hosts with same hardware but different libvirt versions and wonder why they lost a cpu feature. > Note that this does not discard this patch series - I think we'll need a > solution > like this to deal with older VMs that define these features in their XMLs. > > > Thanks, > > > DHB > > >> This will make libvirt add it to the qemu commandline like: >> -cpu ...,osxsave=off,ospke=off >> >> And that will crash when qemu starts with: >> error: internal error: process exited while connecting to monitor: >> 2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global >> core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found >> >> There are much more long term discussions about demoting and dropping qemu >> features and I'd like to avoid those discussions being mixed. >> The reason to drop it more or less without notice was that it never did >> anything to begin with. Due to that our solution might in a similar fashion >> be more trivial - just stop defining those two features to qemu commandline. >> >> [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4... >> [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb6... >> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html >> [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195 >> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848 >> >> Christian Ehrhardt (2): >> qemu: do not define known no-op features >> qemuxml2argvtest: add test for remove cpu features >> >> src/qemu/qemu_command.c | 23 +++++++++++++++ >> .../qemuxml2argvdata/cpu-host-model-cmt.args | 2 +- >> .../cpu-no-removed-features.args | 29 +++++++++++++++++++ >> .../cpu-no-removed-features.xml | 23 +++++++++++++++ >> tests/qemuxml2argvdata/cpu-tsc-frequency.args | 4 +-- >> tests/qemuxml2argvtest.c | 1 + >> 6 files changed, 79 insertions(+), 3 deletions(-) >> create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args >> create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml >>