[libvirt] ARM KVM GICv3 Support

[Daniel P. Berrange]

On Tue, Feb 02, 2016 at 12:49:33PM +0100, Christoffer Dall wrote:
> On Fri, Jan 22, 2016 at 02:44:32PM +0000, Daniel P. Berrange 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 have just recently merged support for registering properties against
> > classes instead of object instances. There is also a proposed command
> > to allow querying the list of properties against a class
> > 
> >   https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04348.html
> > 
> > So if we now update the machine types to register their properties against
> > the class instead of object, then we can query what properties are present
> > against each machine type, while still using '-M none'.
> > 
> > >  (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.)
> > 
> > Our introspection support in QOM only allows us to say that a property
> > is a particular type (int / enum / str / whatever). We don't have any
> > way to expose info about what subset of possible values for a type are
> > permitted. So I don't see any near term way to inform apps that the
> > gic property accepts values x, y and but not z.
> > 
> > IMHO, we shouldn't try to overthink this. Libvirt can query the host
> > to find out what GIC versions are supported and default to using the
> > most recent version, on the basis that people are likely to have a
> > matching QEMU. We can just rely on QEMU to report error if we pass
> > it a version it doesn't support and not try to pre-emptively check
> > before launch. The key is just getting the default right IMHO.
> > 
> This sounds fine to me.
> 
> However, not being familiar with the internals of libvirt I really can't
> just what the right implementation approach here is.
> 
> As I understand we need to either:
> 
>   1) Add a QMP command that lets you ask for -M virt, if GIC version X
>      is supported
> 
>   2) Just implement something in libvirt that checks what the kernel
>      supports directly via the well-defined KVM interface and chooses
>      the highest supported version per default.
> 
> To me it sounds like we should just go ahead with (2) and document
> somehwere that if you get an error, you need to either manually change
> the gic version setting in your VM definition file or upgrade QEMU.
> 
> Can someone with libvirt authority please advice whether (1) or (2) is
> what we need to do?

IMHO we should just go for 2.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|