qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/arm: set machine 'virt' as default


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH] hw/arm: set machine 'virt' as default
Date: Thu, 19 Sep 2019 11:34:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 9/18/19 11:56 PM, Dan Streetman wrote:
> On Wed, Sep 18, 2019 at 4:34 PM Alex Bennée <address@hidden> wrote:
>>
>> Dan Streetman <address@hidden> writes:
>>
>>> From: Dan Streetman <address@hidden>
>>>
>>> There is currently no default machine type for arm so one must be specified
>>> with --machine.  This sets the 'virt' machine type as default.
>>
>> We should really have a FAQ entry for why we don't have a default for
>> ARM. In short unlike PC's every ARM device is different so it pays to be
>> precise about what you want when you invoke QEMU. Because any given
>> kernel/image is only likely to work on the machine it's built for.
> 
> well, that's the problem, I have no idea at all what I want; and "I"
> doesn't really apply completely in this situation, as the call to run
> qemu comes from deep inside a test suite, and can run on multiple
> archs, and could even be run by other people on other systems/archs.
> 
> This is what I have (tentatively) come up with to handle this in the test 
> suite:
> https://github.com/systemd/systemd/pull/13409/files#diff-2ea30ffea3b108e0f9c50846cfdcd4e5R197
> 
> To be fair, it's unlikely that other people would run this on an arm
> system, unless they were a bit more familiar with arm, and maybe would
> know what machine type to pick.  Similarly for the testbeds that I
> handle for this test suite, I know that 'virt' seems to work.
> 
>>
>> Why is virt special? It's just one of the many machines we emulate and
>> while it's probably the most popular these days for "something that
>> boots a Linux distro" why not -machine sba (when that comes)?

This was my first reaction too, why not use the SBSA machine as default?

> I am certainly not the right person to pick what the default should
> be, but I do think there should be *some* default.  If 'virt' is the
> most popular and/or has the widest kernel support, then it probably
> makes sense to make that the default.
> 
> I would guess that users of qemu-system-aarch64 (or -arm) fall into 2 groups:
> 
> 1. people who know about arm and know exactly what machine they want to use
> 2. people who don't know about arm and have no idea what machine to use
> 
> group #1 of course can still pick whatever machine they want.  I'm in
> group #2, and I suspect that like most others in the group, I did:
> 
> $ qemu-system-aarch64 ...
> qemu-system-aarch64: No machine specified, and there is no default
> Use -machine help to list supported machines
> $ qemu-system-aarch64 -M ?
> ...shows long list of machines that i'm unfamiliar with...
> virt-2.10            QEMU 2.10 ARM Virtual Machine
> virt-2.11            QEMU 2.11 ARM Virtual Machine
> virt-2.12            QEMU 2.12 ARM Virtual Machine
> virt-2.6             QEMU 2.6 ARM Virtual Machine
> virt-2.7             QEMU 2.7 ARM Virtual Machine
> virt-2.8             QEMU 2.8 ARM Virtual Machine
> virt-2.9             QEMU 2.9 ARM Virtual Machine
> virt-3.0             QEMU 3.0 ARM Virtual Machine
> virt                 QEMU 3.1 ARM Virtual Machine (alias of virt-3.1)
> virt-3.1             QEMU 3.1 ARM Virtual Machine
> 
> (aha! those "virt" machines look generic enough that they'll work...)
> $ qemu-system-aarch64 -M virt ...
> 
> I honestly don't know if it would be better to have a FAQ on why there
> is no default, or just to set a default.  Personally, I'd prefer just
> having a default.
> 
> If you do decide against a default, I would suggest at least printing
> the url to the FAQ entry on why arm doesn't have a default, instead of
> just asking users to pick one out of the -M ? list.

We can also go all the way around to educate users to use the -M flag,
by killing the 'default machine' on all targets.

Personally I also find the default ppc64 machine confusing.

On the X86 side there is a long discussion/debt about when to change the
default i440fx to q35, so having no default at all would fix this other
issue.

>>> Signed-off-by: Dan Streetman <address@hidden>
>>> ---
>>>  hw/arm/virt.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index d74538b021..e9fe888ca2 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -78,6 +78,7 @@
>>>          mc->desc = "QEMU " # major "." # minor " ARM Virtual Machine"; \
>>>          if (latest) { \
>>>              mc->alias = "virt"; \
>>> +            mc->is_default = 1; \
>>>          } \
>>>      } \
>>>      static const TypeInfo machvirt_##major##_##minor##_info = { \
>>
>>
>> --
>> Alex Bennée
>>
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]