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: Dan Streetman
Subject: Re: [Qemu-devel] [PATCH] hw/arm: set machine 'virt' as default
Date: Tue, 15 Oct 2019 12:31:23 -0400

On Thu, Sep 19, 2019 at 5:34 AM Philippe Mathieu-Daudé
<address@hidden> wrote:
>
> 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.

To follow up on this; is the final desicion for arm to not include any default?

Also, will archs that currently do have defaults, have those defaults removed?

Thanks!

>
> 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]