[libvirt] Why "integratorcp" as the default machine type for ARM / AArch64?

[Kashyap Chamarthy]

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