On Tue, Jan 05, 2016 at 07:26:54PM +0100, Andrea Bolognani wrote:
On Tue, 2016-01-05 at 18:14 +0000, Peter Maydell wrote:
Why can libvirt not just run the tool and parse its output? That's what I understood was done for other things, but perhaps I misunderstood. It's the other way around: the tool uses libvirt to implement its checks. Running a command and parsing its output makes sense when the binary (as is the case for QEMU) is developed by a third party; if you control both pieces, it's usually better to stick to C and avoid spawning extra processes. That argument suggests libvirt should just go ahead and do the ioctls to check for GICv2/v3 support, rather than spawning a separate QEMU binary to do the check for it ?
libvirt already has to spawn QEMU and run QMP commands to probe for dozens of other capabilities, so we have very robust code to do that.
Most importantly, as I wrote in a previous mail, if the check is done by QEMU we remove the risk of it and libvirt ever disagreeing.
So do I understand correct that what you're looking for is a QMP command to query for host GIC capabilities? -Christoffer