qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Dan Streetman" <dan.streetman@canonical.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] hw/arm: set machine 'virt' as default
Date: Thu, 19 Sep 2019 11:34:06 +0200	[thread overview]
Message-ID: <bb9bf110-1e5d-22e2-16d5-40a495c7ee84@redhat.com> (raw)
In-Reply-To: <CAOZ2QJNgiB0ZoLAOUGjdFfWa+Hwkbqe=E+KQeOaUMEdvU0-ofw@mail.gmail.com>

On 9/18/19 11:56 PM, Dan Streetman wrote:
> On Wed, Sep 18, 2019 at 4:34 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Dan Streetman <dan.streetman@canonical.com> writes:
>>
>>> From: Dan Streetman <ddstreet@canonical.com>
>>>
>>> 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 <ddstreet@canonical.com>
>>> ---
>>>  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	other threads:[~2019-09-19  9:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 17:24 [Qemu-devel] [PATCH] hw/arm: set machine 'virt' as default Dan Streetman
2019-09-17 17:36 ` Dan Streetman
2019-09-18 20:33 ` Alex Bennée
2019-09-18 21:56   ` Dan Streetman
2019-09-19  9:34     ` Philippe Mathieu-Daudé [this message]
2019-10-15 16:31       ` Dan Streetman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb9bf110-1e5d-22e2-16d5-40a495c7ee84@redhat.com \
    --to=philmd@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=dan.streetman@canonical.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).