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

Post by Kashyap Chamarthy
Hi
I see in the following change, Dan added the default machine types for
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")
+ [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

Kashyap Chamarthy

2018-11-26 11:51:03 UTC

The entries in the table are supposed to reflect the (historical)
QEMU default; in the case of Arm architectures, you're correct that

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.

Post by Andrea Bolognani
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.

Post by Andrea Bolognani
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

Andrea Bolognani

2018-11-26 12:08:20 UTC

Post by Andrea Bolognani
The entries in the table are supposed to reflect the (historical)
QEMU default; in the case of Arm architectures, you're correct that

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.

Post by Andrea Bolognani
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 :)

Post by Andrea Bolognani
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

Kashyap Chamarthy

2018-11-26 12:40:15 UTC

Post by Andrea Bolognani
The entries in the table are supposed to reflect the (historical)
QEMU default; in the case of Arm architectures, you're correct that

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" :-)

Post by Andrea Bolognani
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!