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 <abolo...@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 :|
