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

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

[Dan Streetman]

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.

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 = { \
-- 
2.20.1

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

[Dan Streetman]

On Tue, Sep 17, 2019 at 1:24 PM Dan Streetman
<dan.streetman@canonical.com> wrote:
>
> 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.

just to clarify why anyone would care if there's a default or not, in
case it's not clear, I have a bit more reasoning here:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1844357

Specifically for my use case, I'm enabling systemd's unit tests to run
on Ubuntu testbeds for different archs (x86_64, i386, ppc64el, arm64,
s390x) and arm64 is the only arch where we need to specify a machine
type; all the rest have a default machine type that works fine.  I'd
prefer if we didn't have to specify a machine type for any of the
archs.

For reference, this is the systemd PR to enable use of qemu for all
the archs we have testbeds for:
https://github.com/systemd/systemd/pull/13409

>
> 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 = { \
> --
> 2.20.1
>

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

[Alex Bennée]

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.

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)?

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

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

[Dan Streetman]

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)?

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.


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

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

[Philippe Mathieu-Daudé]

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

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

[Dan Streetman]

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

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