On Wed, Jan 23, 2019 at 10:08:31AM +0100, Andrea Bolognani wrote:
> 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...
In addition do we really need to change the CPU part of replies every
time someone wants to update capabilities? It creates unnecessary
noise and in some cases it might remove some advanced features because
the capabilities were generated on Server CPU.
That's the case of the first patch in this series, you basically
downgrade the CPU used to generate replies. I know, it requires more
effort when preparing patches.
Pavel
>
> [...]
> > @@ -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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
