[libvirt] [PATCH 2/3] qemu: Update x86_64 QEMU 3.0.0 capabilities

Erik Skultety eskultet at redhat.com
Wed Jan 23 13:01:08 UTC 2019


On Wed, Jan 23, 2019 at 12:42:58PM +0100, Pavel Hrdina wrote:
> 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.

Would it be possible to have an on-demand job in our upstream CI that would
regenerate the capabilities? At least for intel, I have some work in progress
on a branch that would add the notion of vendor, so we could have separate
capabilities for let's say AMD and Intel.

Erik




More information about the libvir-list mailing list