[libvirt] [PATCH RFCv2 0/4] Add optional pSeries features

Andrea Bolognani abologna at redhat.com
Wed Feb 7 09:43:56 UTC 2018


On Tue, 2018-02-06 at 21:25 +0100, Peter Krempa wrote:
> On Tue, Feb 06, 2018 at 17:54:55 +0100, Andrea Bolognani wrote:
> > Applies on top of [req].
> > 
> > RFC because we still don't have a way of probing QEMU to figure
> > out whether the relevant toggles are available. Plus, there's no
> > documentation yet :)
> 
> I wanted to moan about missing docs and sub-par commit messages but
> okay. Note that without documentation it's not possible to scrunitize
> whether it makes any particular sense to expose a given feature at all.

See https://bugzilla.redhat.com/show_bug.cgi?id=1525599#c4 for a
rationale on having the toggles. The previous comment lists all
QEMU-level toggles, and as you can see we're not implementing
either VSX or DFP because they don't have a clear use case.

> Since probing is not implemented I don't think it makes sense to
> introduce cabapility bits for every single feature since they are
> grouped under the same version check.
> 
> Even if qemu adds QMP probing of these the capability check will not go
> away since it would create a regression in behaviour. This means that
> you can remove all the capability bits and group all of them under a
> single one since they will only ever be enabled using that version
> check.

The capabilities have been introduced during the 2.12 development
cycle, so assuming QMP probing makes it into that release we should
definitely use that instead of performing a version check. If it
doesn't then yeah, a version check will probably be better in order
not to artificially block perfectly good QEMU binaries from using
the capabilites. It would still not be a regression, though.

> Also I really don't think that every single feature should have it's own
> XML document to test it. You can gradually add them to a single one and
> test that all are added.

Good point, I'll merge them.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list