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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
