Re: ARM KVM GICv3 Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 06, 2016 at 01:30:16PM +0000, Peter Maydell wrote:
> On 6 January 2016 at 12:49, Andrea Bolognani <abologna@xxxxxxxxxx> 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.

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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]