[libvirt] Why "integratorcp" as the default machine type for ARM / AArch64?
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"? PS: I thought "integratorcp" board was picked as it was probably the first entry when you run `qemu-system-aarch64 -machine help`, but that wasn't the case on my Fedora-28 machine---it was the 12th entry. -- /kashyap
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
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
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.
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 :)
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
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
participants (2)
-
Andrea Bolognani -
Kashyap Chamarthy