Fix default CPU model for ARM64
PATCH 1/1 Fix default CPU model for ARM64
This small patch fixes a long-standing bug: A15 model is used by default
also on ARM64 target. As a result, attempt to run the VM without explicit -cpu specification does not do anything good.
--- hw/arm/virt.c | 4 ++++ 1 file changed, 4 insertions(+)
hw/arm/virt.c +4 -0
@@ -785,7 +785,11 @@ static void machvirt_init(MachineState *machine)char **cpustr;if (!cpu_model) { +#ifdef TARGET_AARCH64 + cpu_model ="cortex-a57" ; +#else cpu_model ="cortex-a15" ; +#endif }/* Separate the actual CPU model name from any appended features */
Signature · 1 line
1.9.5.msysgit.0
Quoted 14 lines · Pavel Fedin
This small patch fixes a long-standing bug: A15 model is used by default
also on ARM64 target. As a result, attempt to run the VM without explicit -cpu specification does not do anything good.Signed-off-by Pavel Fedin <[email protected]>--- hw/arm/virt.c | 4 ++++ 1 file changed, 4 insertions(+)hw/arm/virt.c +0
-0
hw/arm/virt.c static void machvirt_init(MachineState *machine) · line 793
Quoted 9 lines
hw/arm/virt.c +4
-0@@ -785,7 +785,11 @@ static void machvirt_init(MachineState *machine)char **cpustr;if (!cpu_model) { +#ifdef TARGET_AARCH64 + cpu_model ="cortex-a57" ; +#else cpu_model ="cortex-a15" ; +#endif }
I'm afraid this is wrong -- the same command line on qemu-system-arm and qemu-system-aarch64 should do the same thing.
I agree that the current behaviour is confusing but I don't think this is the correct way to fix it.
-- PMM
Hello!
Quoted 2 lines
I'm afraid this is wrong -- the same command line on qemu-system-arm and qemu-system-aarch64 should do the same thing.
But 64-bit A15 is nonsense, because it's 32-bit CPU, isn't it?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Quoted 6 lines · Pavel Fedin
Hello!
Quoted 2 lines
I'm afraid this is wrong -- the same command line on qemu-system-arm and qemu-system-aarch64 should do the same thing.
But 64-bit A15 is nonsense, because it's 32-bit CPU, isn't it?
Yes. qemu-system-aarch64 -cpu cortex-a15 gets you a 32-bit Cortex-A15. This is exactly like the x86 QEMU, where you can emulate all the 32-bit x86 CPUs in qemu-system-x86_64.
-- PMM
Hello!
Quoted 3 lines
Yes. qemu-system-aarch64 -cpu cortex-a15 gets you a 32-bit Cortex-A15. This is exactly like the x86 QEMU, where you can emulate all the 32-bit x86 CPUs in qemu-system-x86_64.
And what is the default in x86_64 ? I believe it's 64-bit CPU, and not i686, isn't it ?
I agree that -cpu cortex-a15 might work with qemu-system-aarch64. But isn't it expected to get the "native" CPU by default ? This behavior of qemu causes weird thing with libvirt/virt-manager. I create a VM, specify "aarch64" as architecture, and set "hypervisor default" as CPU model. With "hypervisor default" libvirt does not pass any -cpu option to qemu, leaving it up to the emulator (exactly as expected). So, i supply 64-bit kernel and rootfs, and nothing works. I have to explicitly change the CPU to "cortex-a57". Isn't it confusing to have such a default ? This is even more confusing since currently i don't know any implementation of aarch64 except A57 and A53 (which are the same from software point of view). So, i believe, A57 is quite a reasonable default.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Quoted 10 lines · Pavel Fedin
Hello!
Quoted 3 lines
Yes. qemu-system-aarch64 -cpu cortex-a15 gets you a 32-bit Cortex-A15. This is exactly like the x86 QEMU, where you can emulate all the 32-bit x86 CPUs in qemu-system-x86_64.
And what is the default in
x86_64? I believe it's 64-bit CPU, and not i686, isn't it ?
I agree that -cpu cortex-a15 might work with qemu-system-aarch64. But isn't it expected to get the "native" CPU by default ? This behavior of qemu causes weird thing with libvirt/virt-manager. I create a VM, specify "aarch64" as architecture, and set "hypervisor default" as CPU model. With "hypervisor default" libvirt does not pass any -cpu option to qemu, leaving it up to the emulator (exactly as expected). So, i supply 64-bit kernel and rootfs, and nothing works. I have to explicitly change the CPU to "cortex-a57". Isn't it confusing to have such a default ? This is even more confusing since currently i don't know any implementation of aarch64 except A57 and A53 (which are the same from software point of view). So, i believe, A57 is quite a reasonable default.
FWIW virt-manager 1.2.0 (just released) will do the following when creating a new VM:
- aarch64 + kvm : -cpu host
- aarch64 + tcg : -cpu cortex-a57
- arm32 + kvm : -cpu host
- arm32 + tcg : defer to qemu
Though if you explicitly request 'hypervisor default' then we won't specify any -cpu and defer to qemu, which will hit the cortex-a15 default for aarch64
- Cole
Hello!
Quoted 10 lines
FWIW virt-manager 1.2.0 (just released) will do the following when creating a new VM:
- aarch64 + kvm : -cpu host
- aarch64 + tcg : -cpu cortex-a57
- arm32 + kvm : -cpu host
- arm32 + tcg : defer to qemuThough if you explicitly request 'hypervisor default' then we won't specify any -cpu and defer to qemu, which will hit the cortex-a15 default for aarch64
virt-manager is not the only tool to create VMs...
But, okay. Seems you just don't want to change this. Well... I still don't agree and this
default looks strange for me, but it's just me. I'm out of further arguments.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Quoted 10 lines · Pavel Fedin
Hello!
Quoted 8 lines
FWIW virt-manager 1.2.0 (just released) will do the following when creating a new VM:
- aarch64 + kvm : -cpu host
- aarch64 + tcg : -cpu cortex-a57
- arm32 + kvm : -cpu host
- arm32 + tcg : defer to qemu
Quoted 7 lines
Quoted 2 lines
Though if you explicitly request 'hypervisor default' then we won't specify any -cpu and defer to qemu, which will hit the cortex-a15 default for aarch64
virt-manager is not the only tool to create VMs...
But, okay. Seems you just don't want to change this. Well... I still don't agree and this
default looks strange for me, but it's just me. I'm out of further arguments.
I think the real bug is the naming scheme for QEMU targets. QEMU targets such as Aarch64 and x86_64 are following the long established convention of using an ISA for a name, but are ultimately badly named as they support multiple ISAs beyond what their singular name suggests.
"qemu-system-arm" would be the be the best name for the works-for-all-ARM QEMU but that name is taken. But if we are true to qemu-system-aarch64 being a functional superset of arm, can we just unify as the one arch ("arm") and phase out qemu-system-aarch64 (would become an alias of qemu-system-arm)?. Linux user builds are the main complication, but that is the case where it very much does make sense to tie to an ISA. Ignoring legacy, the ideal naming scheme would be:
qemu-system-arm
aarch64-linux-user
aarch32-linux-user
Regards,
Peter
Regards,
Peter
Quoted 7 lines
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Hello!
Quoted 5 lines
Ignoring legacy, the ideal naming scheme would be:
qemu-system-arm
aarch64-linux-user
aarch32-linux-user
You know, i rethought. Actually, the question concerns only "virt" machine, because for other real machines the CPU should be the same as on real HW, and this is no question. Shouldn't our default for "virt" be just "host" ? This would eliminate all ambiguity i believe...
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Quoted 10 lines · Pavel Fedin
Hello!
Quoted 5 lines
Ignoring legacy, the ideal naming scheme would be:
qemu-system-arm
aarch64-linux-user
aarch32-linux-userYou know, i rethought. Actually, the question concerns only "virt" machine, because for other real machines the CPU should be the same as on real HW, and this is no question. Shouldn't our default for "virt" be just "host" ? This would eliminate all ambiguity i believe...
What's it then meant to do for TCG (where the host could be anything)?
And I think this is still an issue as it will be a functional diff between qemu-system-arm and qemu-system-aarch64 breaking compatability between the too and forever committing us to have to maintain two builds.
Regards,
Peter
Quoted 7 lines
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
Quoted 10 lines · Pavel Fedin
Hello!
Quoted 8 lines
FWIW virt-manager 1.2.0 (just released) will do the following when creating a new VM:
- aarch64 + kvm : -cpu host
- aarch64 + tcg : -cpu cortex-a57
- arm32 + kvm : -cpu host
- arm32 + tcg : defer to qemu
Quoted 6 lines
Quoted 2 lines
Though if you explicitly request 'hypervisor default' then we won't specify any -cpu and defer to qemu, which will hit the cortex-a15 default for aarch64
virt-manager is not the only tool to create VMs...
But, okay. Seems you just don't want to change this. Well... I still don't agree and this
default looks strange for me, but it's just me. I'm out of further arguments.
Actually I agree with your patch. It's the same that x86 does.
Paolo
Quoted 10 lines · Pavel Fedin
Hello!
Quoted 8 lines
FWIW virt-manager 1.2.0 (just released) will do the following when creating a new VM:
- aarch64 + kvm : -cpu host
- aarch64 + tcg : -cpu cortex-a57
- arm32 + kvm : -cpu host
- arm32 + tcg : defer to qemu
Quoted 7 lines
Quoted 2 lines
Though if you explicitly request 'hypervisor default' then we won't specify any -cpu and defer to qemu, which will hit the cortex-a15 default for aarch64
virt-manager is not the only tool to create VMs...
But, okay. Seems you just don't want to change this. Well... I still don't agree and this
default looks strange for me, but it's just me. I'm out of further arguments.
I wasn't implying any opinion about your proposed patch, just clarifying the details about how latest virt-manager performs since you mentioned it upthread. FWIW I agree with the idea of your patch
- Cole