[libvirt] ARM KVM GICv3 Support

[Andrea Bolognani]

On Sat, 2016-01-09 at 16:01 +0100, Christoffer Dall wrote:
> On Wed, Jan 06, 2016 at 01:30:16PM +0000, Peter Maydell wrote:
> > On 6 January 2016 at 12:49, Andrea Bolognani <abologna at redhat.com> wrote:
> > > That's correct, having a QMP command that lists the values gic-version
> > > can have on the current host would be just great.
> > > 
> > > If we had that, we could validate the GIC version chosen for a guest,
> > > and expose it in the capabilities XML so that higher-level tools can
> > > provide a list of choices to the user.
> > > 
> > > Please note that this QMP command would have to work regardless of the
> > > machine type selected on QEMU's command line, because libvirt always
> > > runs a QEMU binary with '-M none' when probing its capabilities.
> > 
> > On the other hand, if you don't tell us the machine type you care
> > about then we can't tell you:
> >  (a) "this machine type doesn't support setting this property at all"
> >      (which applies to machines like vexpress-a15 which you can use with
> >      KVM on 32-bit hosts, and of course also to all the non-KVM models)

We only allow specifying the GIC version for the 'virt' machine type,
so this shouldn't be a problem.

> >  (b) "this machine type only supports GIC versions X and Y even if the
> >       host supports more" (this is currently only hypothetical, though,
> >       since we only have the property on 'virt'. it would only happen
> >       if in the future we needed something other than '2' or '3' or
> >       'host' I think.)

See below.

> > If you use -M none then we can only tell you information you
> > could have got yourself by directly asking the kernel about it.

Sure. But the idea of having QEMU report this information, instead of
probing for it directly, was to make sure that the whole stack agreed
on a bunch of values that could be used, so that we could never find
ourselves in the situation where eg. GICv4 is out, libvirt probes for
it and believes it can be used, but since the QEMU binary on the system
is old and it doesn't know about GICv4 it errors out.

> So where does this leave us?  Do we need a QMP command or not?
> 
> It sounds to me like we should implement one, and the answer depends on
> the machine option chosen, where -M none gives you the generic
> capabilities of the kernel and for other machines it tells you what's
> possible?

libvirt probes QEMU for its capabilities using '-M none', but we should
be able to extend its probing routines to look for features that are
known to be machine type specific, such as gic-version, by specifying
the appropriate machine type.

Would providing a QMP command that returns the list of GIC versions
available on the current host for the current machine type be
acceptable from QEMU's point of view?

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team