On Mon, Nov 26, 2018 at 01:08:20PM +0100, Andrea Bolognani wrote: > 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. Oops, you're right. It is the other way around: the default *CPU* type depends on the board model (i.e. machine type) for ARM / AArch64. And speaking of which, as Peter Maydell put it on IRC once: "some board models will ignore any user specificed CPU type; some will error out if you pick one it can't handle; some will silently try to use it and may be functional or may not" :-) > > > 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 :) Thanks! > > > 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. Ah, right; I should've also tried the QMP. Makes sense. Thanks for the clarification. > 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. -- /kashyap -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
