On Tue, Feb 16, 2016 at 11:10:55AM +0100, Markus Armbruster wrote: > Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > > > On 15 February 2016 at 20:18, Andrew Jones <drjones@xxxxxxxxxx> wrote: > >> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote: > >>> How would the command line look like? > >>> > >> > >> Here is what is available today > >> > >> # select gicv2 (this work with and without KVM) > >> qemu-system-aarch64 -M virt # v2 is the default > >> qemu-system-aarch64 -M virt,gic-version=2 ... > >> > >> # select gicv3 (only works with KVM) > >> qemu-system-aarch64 -M virt,gic-version=3 ... > > > > This will work with TCG once we get the GICv3 emulation upstream. > > > >> # select whatever the host has > >> qemu-system-aarch64 -M virt,gic-version=host ... > > > > This only works with KVM (like -cpu host). > > Aha, it's a machine option. Therefore, the generic direct solution > would be command line introspection. A couple of remarks. > > We don't have comprehensive command line introspection. There's only > query-command-line-options, but it's incomplete and insufficiently > expressive. We usually sidestep command line introspection and > introspect the corresponding QMP command, or we "look for a witness" in > QMP, i.e. some introspectible indicator for the non-introspectible > feature we need to know. > > The is no QMP command corresponding to --machine. There's a long term > vision to start QEMU with a blank slate, then configure everything via > QMP. With that, QMP introspection would cover machine options. Of > course, visions aren't going to help you now. > > Even if there was a QMP command, the way we do --machine options would > defeat QMP introspection: they're QOM properties, defined in code. > > Defining things in code is the most flexible solution, but it makes > reasoning about them *much* harder: the only general way to learn what > code does is run it. This is fundamentally incompatible with > introspection. In other words, QOM's design sacrifices > introspectability for flexibility. The flexibility isn't actually > needed most of the time, but it defeats introspection all of the time. > For me, this was an design mistake. We made the same mistake before, > with migration. > > I figure we'll need to crack the QOM introspection problem to at least > some useful degree. But it's going to be a lot of work. > > A less flexible, introspectible, data-driven interface could be layered > on top of the code-driven one. With as many users as possible converted > to the data-driven interface, the flexibility then defeats introspection > only where we actually use the flexibility. > > Back to GIV. Recognized values of gic-version are fixed at compile > time: 2, 3, host. Once again, QOM does things in code rather than data: > the set of values is defined in the setter function > virt_set_gic_version(). > > Some values are accepted only together with other configuration: 3 > requires accel=kvm (for now), host requires -cpu host. Static > introspection can't show such constraints. > > Would the proposed query-gic-capability show them? How? Also bear in mind that libvirt probes capabilities using '-m none' so you're not going to have any 'virt' machine type instantiated when probing is done. 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