On Tue, 2019-01-22 at 12:46 -0500, John Ferlan wrote:
> Regenerate the output from the QEMU v3.0.0 tag using
>
> ./configure --target-list=x86_64-softmmu \
> --disable-strip \
> --disable-fdt \
> --disable-xen \
> --disable-werror \
> --enable-debug \
> --enable-system \
> --enable-user \
> --enable-linux-user \
> --with-pkgversion=v3.0.0
>
> NB: I had to fudge in the qemu-sev-capabilities output from
> commit d4005609f3 (not sure if there's a specific package
> to allow it just from build).
While I very much appreciate the effort and agree it's something
that we should do, you can't just mix and match replies like that,
otherwise you'll end up with nonsensical results such as...
[...]
> @@ -19181,7 +19180,7 @@
> "kvm-pv-tlb-flush": true,
> "tbm": false,
> "wdt": false,
> - "model-id": "Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz",
> + "model-id": "Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz",
... an Intel CPU...
[...]
> @@ -20321,11 +20320,13 @@
> }
>
> {
> - "id": "libvirt-50",
> - "error": {
> - "class": "GenericError",
> - "desc": "SEV feature is not available"
> - }
> + "return": {
> + "reduced-phys-bits": 1,
> + "cbitpos": 47,
> + "cert-chain": "AQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAA",
> + "pdh": "AQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAA"
> + },
> + "id": "libvirt-50"
> }
... suddenly supporting SEV, which is an AMD-specific feature.
The only sane way to deal with the situation is picking a few
QEMU versions and generate the corresponding capabilities on an
SEV-capable AMD host; then it's only a matter of making sure SEV
testing is performed against those specific QEMU versions rather
than random ones.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
