On Tue, Dec 15, 2015 at 05:53:43PM +0100, Andrea Bolognani wrote: > On Tue, 2015-12-15 at 10:35 -0600, Andrew Jones wrote: > > On Tue, Dec 15, 2015 at 04:03:13PM +0000, Peter Maydell wrote: > > > On 15 December 2015 at 14:12, Martin Kletzander <mklet...@redhat.com> > > > wrote: > > > > On Tue, Dec 15, 2015 at 09:41:02AM +0000, Peter Maydell wrote: > > > > > > > > > > On 15 December 2015 at 09:36, Martin Kletzander <mklet...@redhat.com> > > > > > wrote: > > > > > > > > > > > > We do pass some options, for example, you can restrict the GIC to > > > > > > v2: > > > > > > https://libvirt.org/formatdomain.html#elementsFeatures > > > > > > > > > > > > That could be modified to work for your purpose IIUC, right? > > > > > > > > > > > > > > > What does that option do to the QEMU command line? The documentation > > > > > doesn't seem to say. > > > > > > > > > > > > > It appends gic-version= to the machine option, if bunch of conditions > > > > are met -- it has to be ARM machine, it has to be something else than > > > > version 2, and so on, more details are visible in the code and I won't > > > > cover them here. I hope that's understandable. > > > > > > OK. So it should be sufficient just to have > > > <gic version='host'/> > > > which will then provide whatever VGIC the host machine can do with > > > hardware acceleration. > > > > This is probably good for guests that happy with both. Guests that > > need/want a specific choice will put their integer there, and then > > we need a way to do a capabilities check before launching that guest > > on an arbitrary host. > > That won't work at the moment since we're expecting the value to be a > number, but extending it so that 'host' is accepted as well should be > easy to do in a backwards-compatible way. > > The behaviour of the value '2' has been defined as "don't specify any > GIC version" though, and I'm afraid we'll be unable to change that > because it would affect existing guests. Martin can probably weigh in. > > Having a way for libvirt to know what values can be used on the specific > machines it's running on it's another topic altogether - is there a good > way to detect it? Is that based on the hardware, on the QEMU binary, on > the machine type?
My understanding of libvirt host feature probing is that it generally queries QEMU, rather than the host directly. QEMU using Andre's ioctl test, when asked with QEMU's command line using some '\?' type of input, seems like the typical approach to me. Thanks, drew -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
