On Mon, Nov 26, 2018 at 12:29:45PM +0100, Andrea Bolognani wrote: > On Mon, 2018-11-26 at 11:23 +0100, Kashyap Chamarthy wrote: > > Hi > > > > I see in the following change, Dan added the default machine types for > > all architectures: > > > > https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=26cfb1a3 > > ("qemu: ensure default machine types don't change if QEMU changes") > > > > What caught my eye was the default machine type chosen ("integratorcp") > > for ARM / AAarch64: > > > > + [VIR_ARCH_ARMV7L] = "integratorcp", > > + [VIR_ARCH_ARMV7B] = "integratorcp", > > + > > + [VIR_ARCH_AARCH64] = "integratorcp", > > > > I thought the default for AArch64 / ARM would be 'virt'---as I learnt > > that upstream QEMU explicitly designed the 'virt' board for ARM / > > AArch64-based machine machines (because it supports PCI, 'virtio', has > > decent RAM limits, etc.) > > > > So, shouldn't the default for the above be changed from "integratorcp" > > to "virt"? > > 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. > 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. > 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). > > Of course that's not really what users expect, so any application > paying more than lip-service to Arm support will already be asking > for a virt machine explicitly, and a properly-built application will > be looking for that information in libosinfo instead - and getting > back virt as the recommendation. Yep, noted. -- /kashyap -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
