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:
[danielhb@rekt libvirt]$ sudo ./run tools/virsh capabilities
[sudo] password for danielhb:
<capabilities>
<host>
<uuid>985fc2cc-23a6-11b2-a85c-a1357d626e56</uuid>
<cpu>
<arch>x86_64</arch>
<model>Skylake-Client-IBRS</model>
<vendor>Intel</vendor>
<microcode version='150'/>
<topology sockets='1' cores='4' threads='2'/>
(...)
<feature name='pdcm'/>
<feature name='osxsave'/>
(...)
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.
But I am wondering here, fully aware that you mentioned that you wanted this
discussion to be avoided, 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.
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=f1a23522b03a569f13aad49294bb4c4b1a9500c7
[2]:
https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
[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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
