[libvirt] ARM KVM GICv3 Support
Daniel P. Berrange
berrange at redhat.com
Tue Feb 2 12:10:10 UTC 2016
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 :|
More information about the libvir-list
mailing list