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. > > I realized the information is already sort of exposed by QEMU: > > > > $ qemu-system-aarch64 -machine virt,? > > ... > > virt.gic-version=string (Set GIC version. Valid values are 2, 3 and host) > > ... > > > > Not the best format to parse, but the information is there. And we > > already have some code to extract such parameters from QEMU using QMP's > > query-command-line-options command![1] > > Note that helpstring will tell you whether the qemu you have supports > the machine parameter, but not whether the host CPU supports > GICv2 or 3 (or both) -- it's just a fixed string. Right, thanks for pointing that out :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list