ARCH_CAPABILITIES guest capability detection

[Christian Ehrhardt ]

We would want full arch-caps handling in Eoans libvirt.
The work started for bug 1828495 brought us proper host and some guest work (qemu is fine, but libvirt is lacking).

capability detection works fine and for that I'll upload.

--- old.c.xml 2019-08-22 13:00:10.381464090 +0000
+++ new.c.xml 2019-08-22 13:02:16.907483989 +0000
@@ -37,6 +37,10 @@
       <feature name='mbm_total'/>
       <feature name='mbm_local'/>
       <feature name='invtsc'/>
+ <feature name='rdctl-no'/>
+ <feature name='ibrs-all'/>
+ <feature name='skip-l1dfl-vmentry'/>
+ <feature name='mds-no'/>
       <pages unit='KiB' size='4'/>
       <pages unit='KiB' size='2048'/>
       <pages unit='KiB' size='1048576'/>

But guest caps are detected as not-supported so far.
One would think that kernel and/or qemu are unable to do so, but forcing them in:
  <qemu:commandline>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='Cascadelake-Server,ss=on,vmx=on,hypervisor=on,tsc_adjust=on,umip=on,pku=on,md-clear=on,stibp=on,arch-capabilities=on,xsaves=on,invtsc=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on'/>
  </qemu:commandline>

That made the guest start with these features.
Which implies qemu can pass/use them.

Therefore we uploaded ubuntu4 with the fully working host feature detection, but need to fixup the guest detection and passing.

[Christian Ehrhardt  (paelzer)]

On the "same" libvirt code I can detect the features just right by copying in an upstream build of recent qemu.
So either this actually misses qemu changes to fully work OR libvirt needs code to better work with "older" qemu.

[Christian Ehrhardt  (paelzer)]

qemu head (4.2 dev) - works
v4.1.0 - works
v4.0.0 - fails (well we know it is post 4.0 code so that is fine).

That called for a bisect:

BAD = once the feature is detected:
git bisect start
# bad: [9e06029aea3b2eca1d5261352e695edc1e7d7b8b] Update version for v4.1.0 release
git bisect bad 9e06029aea3b2eca1d5261352e695edc1e7d7b8b
# good: [131b9a05705636086699df15d4a6d328bb2585e8] Update version for v4.0.0 release
git bisect good 131b9a05705636086699df15d4a6d328bb2585e8
# good: [aae65009726858390d8bfca73d795613698f317a] s390x/tcg: Export float_comp_to_cc() and float(32|64|128)_dcmask()
git bisect good aae65009726858390d8bfca73d795613698f317a
# skip: [efa85a4d1ab13e962c0a93d09b7e935571d669fe] Merge remote-tracking branch 'remotes/philmd-gitlab/tags/pflash-next-20190701' into staging
git bisect skip efa85a4d1ab13e962c0a93d09b7e935571d669fe
# bad: [b28f582c2acaca26b66262d75cc5a0bd2764482c] iotests: Let 233 run concurrently
git bisect bad b28f582c2acaca26b66262d75cc5a0bd2764482c
# bad: [14e714900f6b90b35ae2b040d300f95581a416f4] spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges
git bisect bad 14e714900f6b90b35ae2b040d300f95581a416f4
# good: [2fc0cc0e1e034582f4718b1a2d57691474ccb6aa] target/arm: Use env_cpu, env_archcpu
git bisect good 2fc0cc0e1e034582f4718b1a2d57691474ccb6aa
# good: [677c4d69ac21961e76a386f9bfc892a44923acc0] cpu: Move ENV_OFFSET to exec/gen-icount.h
git bisect good 677c4d69ac21961e76a386f9bfc892a44923acc0
# bad: [506174bf8219dc6d56d2b1f7e66e8cf39157466f] i386: "unavailable-features" QOM property
git bisect bad 506174bf8219dc6d56d2b1f7e66e8cf39157466f
# good: [65b23204d609c5aac819049c2d7314b4abd73122] tcg/aarch64: Use LDP to load tlb mask+table
git bisect good 65b23204d609c5aac819049c2d7314b4abd73122
# good: [43b3952dea0f763ceeaa2f119c473b5cc6d29c90] tcg/arm: Remove mostly unreachable tlb special case
git bisect good 43b3952dea0f763ceeaa2f119c473b5cc6d29c90
# good: [5a853fc57a0860da4a55d1448a77845f97e7a9be] i386: x86_cpu_list_feature_names() function
git bisect good 5a853fc57a0860da4a55d1448a77845f97e7a9be
# first bad commit: [506174bf8219dc6d56d2b1f7e66e8cf39157466f] i386: "unavailable-features" QOM property

P.S. some nice fast build time helped this bisect :-)

[Christian Ehrhardt  (paelzer)]

That identified:
506174bf8219dc6d56d2b1f7e66e8cf39157466f is the first bad commit
commit 506174bf8219dc6d56d2b1f7e66e8cf39157466f
Author: Eduardo Habkost <email address hidden>
Date: Mon Apr 22 20:47:42 2019 -0300

    i386: "unavailable-features" QOM property

    Add a "unavailable-features" QOM property to X86CPU objects that
    have the same semantics of "unavailable-features" on
    query-cpu-definitions. The new property has the same goal of
    "filtered-features", but is generic enough to let any kind of CPU
    feature to be listed there without relying on low level details
    like CPUID leaves or MSR numbers.

    Message-Id: <email address hidden>
    Signed-off-by: Eduardo Habkost <email address hidden>

[Christian Ehrhardt  (paelzer)]

And this makes sense, when porting the libvirt part we have seen it relies on unavailable-features, but I'd back then thought that would be via query-cpu-definitions.
But obviously (as libvirt will use QOM) it needs it here.

So our qemu in Eoan (and our arch_capability backports) lack this change (and maybe some context) to make qemu able to talk with libvirt about the arch-capability features correctly.

I'm going to try identifying what we need in Eoan on top on what we have.

[Christian Ehrhardt  (paelzer)]

Related libvirt changes:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=0d254bce
https://libvirt.org/git/?p=libvirt.git;a=commit;h=8eb4a89f

[Christian Ehrhardt  (paelzer)]

Test PPA [1] confirmed to work in Eoan.
Will propose an MP for those qemu changes.

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/experimental-eoan-archcap-detection

[Christian Ehrhardt  (paelzer)]

The qemu changes have to go along the libvirt uploads that are at least in consideration for bug 1828495. They are not strictly dependent (none breaks without the other) but the full function of security mitigation usability can only be achieved with both.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu6

---------------
qemu (1:4.0+dfsg-0ubuntu6) eoan; urgency=medium

  * d/p/ubuntu/lp-1841066-*: fix detection of arch_capability flags
    (LP: #1841066)

 -- Christian Ehrhardt <email address hidden> Mon, 26 Aug 2019 12:08:04 +0200