[libvirt] ARM KVM GICv3 Support
Andrea Bolognani
abologna at redhat.com
Tue Jan 5 18:26:54 UTC 2016
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
More information about the libvir-list
mailing list