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