On Mon, 2018-11-26 at 12:51 +0100, Kashyap Chamarthy wrote: > On Mon, Nov 26, 2018 at 12:29:45PM +0100, Andrea Bolognani wrote: > > The entries in the table are supposed to reflect the (historical) > > QEMU default; in the case of Arm architectures, you're correct that > > integratorcp is not the right value, but it should *not* be virt: > > Right, I keep remembering this on-and-off---there is no default machine > type for ARM architectures, and that it depends on the CPU model > configured. I don't think it depends on the CPU model at all: you are just supposed to provide one explicitly every single time. > > QEMU simply has no default for those architectures, so we should set > > the entires above to NULL and let libvirt go through the usual > > Can send that trivial patch, if someone is already not on it. I have a patch ready, so you can save the effort; additionally, regardless of who sends the patch I would like Dan to review it to make sure I didn't miss anything in my reasoning :) > > process of looking for QEMU's default machine type, not finding one, > > and falling back to using the first entry in the list (on my system > > that would be akita). Small correction: the list from which libvirt will choose the first item as fallback is *not* the output of 'qemu -machine help' but rather the result of running the 'query-machines' QMP command. At least on my system, that will once again result in integratorcp being picked as the default, only it will have been obtained through the correct route this time. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
