The default_cpu_type for the Virt machine is set to "cortex-a15" for
both the arm (qemu-system-arm) and aarch64 (qemu-system-aarch64)
targets.

As a result, starting the aarch64 target with "-machine virt" defaults
to booting with a Arm v7 cpu which is counter to
expectation. Debugging the issue is further hampered by lack of any
output from a supplied arm64 firmware as it is now running on the
wrong CPU type.

Fix this by defaulting to the "max" capability CPU for the target
architecture. After the patch both the arm and aarch64 qemu default to
the equivalent of passing "-cpu max".

Signed-off-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
---
Hi Peter,

I spent inordinately long time scratching my head trying to figure out
why my arm64 VM wasn't booting in TCG mode.

Please consider merging if you don't see any issues with the patch.

Thanks,
Punit

 hw/arm/virt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ecfee362a1..7c5cbdba87 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2424,7 +2424,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
     mc->minimum_page_bits = 12;
     mc->possible_cpu_arch_ids = virt_possible_cpu_arch_ids;
     mc->cpu_index_to_instance_props = virt_cpu_index_to_props;
-    mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-a15");
+    mc->default_cpu_type = ARM_CPU_TYPE_NAME("max");
     mc->get_default_cpu_node_id = virt_get_default_cpu_node_id;
     mc->kvm_type = virt_kvm_type;
     assert(!mc->get_hotplug_handler);
-- 
2.28.0

On Thu, 20 Aug 2020 at 05:55, Punit Agrawal
<punit1.agrawal@toshiba.co.jp> wrote:
>
> The default_cpu_type for the Virt machine is set to "cortex-a15" for
> both the arm (qemu-system-arm) and aarch64 (qemu-system-aarch64)
> targets.
>
> As a result, starting the aarch64 target with "-machine virt" defaults
> to booting with a Arm v7 cpu which is counter to
> expectation. Debugging the issue is further hampered by lack of any
> output from a supplied arm64 firmware as it is now running on the
> wrong CPU type.
>
> Fix this by defaulting to the "max" capability CPU for the target
> architecture. After the patch both the arm and aarch64 qemu default to
> the equivalent of passing "-cpu max".

Hi; this kind of thing has been suggested in the past several times.
Generally we've taken the view that we prefer:
 * not to make changes that would break pre-existing command lines
 * to maintain the general behaviour that a command line used
   with qemu-system-arm will also work with qemu-system-aarch64

It is certainly true that these days the default CPU type for
virt is not what most users want, though.

thanks
-- PMM

Hi Peter,

Thanks for the quick feedback and the background. 

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 20 Aug 2020 at 05:55, Punit Agrawal
> <punit1.agrawal@toshiba.co.jp> wrote:
>>
>> The default_cpu_type for the Virt machine is set to "cortex-a15" for
>> both the arm (qemu-system-arm) and aarch64 (qemu-system-aarch64)
>> targets.
>>
>> As a result, starting the aarch64 target with "-machine virt" defaults
>> to booting with a Arm v7 cpu which is counter to
>> expectation. Debugging the issue is further hampered by lack of any
>> output from a supplied arm64 firmware as it is now running on the
>> wrong CPU type.
>>
>> Fix this by defaulting to the "max" capability CPU for the target
>> architecture. After the patch both the arm and aarch64 qemu default to
>> the equivalent of passing "-cpu max".
>
> Hi; this kind of thing has been suggested in the past several times.
> Generally we've taken the view that we prefer:
>  * not to make changes that would break pre-existing command lines
>  * to maintain the general behaviour that a command line used
>    with qemu-system-arm will also work with qemu-system-aarch64

It did feel like too low hanging a fruit to not have been looked into
before. Generally the above makes sense - though defaulting
qemu-system-aarch64 to start with a 32bit cpu is stretching the above
view too far I think.

> It is certainly true that these days the default CPU type for
> virt is not what most users want, though.

I do understand it's a balancing act when it comes to changing user
visible options. But it's worth revisiting the choice if most users
would prefer otherwise.

Thanks,

Punit