Re: [libvirt] Why "integratorcp" as the default machine type for ARM / AArch64?
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:
QEMU simply has no default for those architectures, so we should set
the entires above to NULL and let libvirt go through the usual
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.
--
Andrea Bolognani / Red Hat / Virtualization