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