[Qemu-devel] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Qemu-devel] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Wainer dos Santos Moschetta]

Peter, Cleber,

Re-sending this email because I forgot to copy the mailing listing.
Sorry. Original message below.

==
Hi Peter et al.,

I came across this when running the acceptance tests in an aarch64 host.
The arch-independent tests fail because, in general, they don't set a
machine type. In order to avoid treating arm targets as special cases
on avocado_qemu framework I prefered to attempt to promote virt as
default for ARM emulation. Moreover since it represents a generic hardware
and its used is broaden advised [1], I found it the right choice.

Maybe that topic was discussed already but I didn't find any reference on
either the mailing list and git logs. It is also true
that I am an ignorant on ARM platform, thus I might be missing
something. Those explain why I send this patch as RFC.

[1] https://wiki.qemu.org/Documentation/Platforms/ARM

Thanks,

Wainer
-- >8 --
Currently none arm target has a default machine type, unlike
others as x86_64 and ppc64. The 'virt' (alias) type represents a
generic ARM hardware, so let's specify it the default machine for
ARM emulation.

Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
---
 hw/arm/virt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 431e2900fd..2f8aa2bfb7 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -74,6 +74,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.18.1

Re: [Qemu-devel] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Peter Maydell]

On Thu, 20 Jun 2019 at 23:23, Wainer dos Santos Moschetta
<wainersm@redhat.com> wrote:
> I came across this when running the acceptance tests in an aarch64 host.
> The arch-independent tests fail because, in general, they don't set a
> machine type. In order to avoid treating arm targets as special cases
> on avocado_qemu framework I prefered to attempt to promote virt as
> default for ARM emulation. Moreover since it represents a generic hardware
> and its used is broaden advised [1], I found it the right choice.

Not providing a default machine type for Arm is a deliberate
choice: there is no single right answer and the user has
to decide what their preference is. We used to have a default
machine type set, and it caused a lot of user confusion as
they expected Arm to be like x86 where everything will run
fine on the default machine type and it did not, which is
why we switched to not having a default.

thanks
-- PMM

Re: [Qemu-devel] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Cleber Rosa]

On Fri, Jun 21, 2019 at 11:33:10AM +0100, Peter Maydell wrote:
> On Thu, 20 Jun 2019 at 23:23, Wainer dos Santos Moschetta
> <wainersm@redhat.com> wrote:
> > I came across this when running the acceptance tests in an aarch64 host.
> > The arch-independent tests fail because, in general, they don't set a
> > machine type. In order to avoid treating arm targets as special cases
> > on avocado_qemu framework I prefered to attempt to promote virt as
> > default for ARM emulation. Moreover since it represents a generic hardware
> > and its used is broaden advised [1], I found it the right choice.
> 
> Not providing a default machine type for Arm is a deliberate
> choice: there is no single right answer and the user has
> to decide what their preference is. We used to have a default
> machine type set, and it caused a lot of user confusion as
> they expected Arm to be like x86 where everything will run
> fine on the default machine type and it did not, which is
> why we switched to not having a default.
> 
> thanks
> -- PMM

The experience acquired here deserves the highest consideration, but I
can't help myself to wonder if this isn't one of the (conceptual)
reasons for parameters such as '-nodefaults'.  I know QEMU doesn't
promise the same behavior across different targets, but that could
improve considerably with very cheap actions.

You can consider me biased (I do consider myself), but trying to wear
the hat of a user first interacting with QEMU, I would expect a (any)
reasonably capable environment that can represent the given target.
That will probably be a different environment than the one I may need,
and I think that's fine.

Now on the functional testing side, this means less code adjusting to
the specifics of each target, and overall, more test code that could
be reused across different targets.  I believe the same to be true
for management layer code.

Anyway, it'd be nice to just double check if keeping things as they
are is in this specific aspect is a firm yes.  If so, tests (and
management layers) will (continue to) have to adapat.

Best,
- Cleber.

Re: [Qemu-devel] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Peter Maydell]

On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <crosa@redhat.com> wrote:
> The experience acquired here deserves the highest consideration, but I
> can't help myself to wonder if this isn't one of the (conceptual)
> reasons for parameters such as '-nodefaults'.  I know QEMU doesn't
> promise the same behavior across different targets, but that could
> improve considerably with very cheap actions.

Yeah, there are probably improvements we could make. The
usual constraints apply:
 * we don't want to break compatibility with existing used
   command lines in the wild
 * ideally, we should be consistent across target architectures
   and across machine types about how things work (this is
   an ideal we obviously don't live up to today in many places)
 * we don't want to back ourselves into awkward corners for
   the future (the qemu-system-arm default machine type was
   originally 'integratorcp' which no doubt made sense in 1998
   or whenever it was, but was nothing but confusing and the
   wrong choice for 99% of users by a decade or so later.
   x86 is kind of an outlier for having such longevity of "all
   hardware looks basically the same".)

> You can consider me biased (I do consider myself), but trying to wear
> the hat of a user first interacting with QEMU, I would expect a (any)
> reasonably capable environment that can represent the given target.
> That will probably be a different environment than the one I may need,
> and I think that's fine.

I'm really not sure what you're trying to suggest here; maybe
you could clarify? If you specify a target (ie a machine type),
you get that machine type. If you don't specify a target, then
we can't really guess what you were hoping to run and
magically pick something that works.

The main problem here is that users expect "all the world is a PC"
type behaviour, ie they can just provide qemu-system-arm or
qemu-system-aarch64 with no command line arguments except
a guest kernel (which is half the time something they found under
a rock or extracted from some firmware image) or a guest CDROM
image and have it boot, because that generally works for x86. It
doesn't and can't work for Arm, because of the much greater
diversity of machine types and the way that kernels are often
only compiled to work on a specific subset of machines.
Making the user specify a machine type means they do at least
get prompted that the world is more complicated than they
think it is and there are decisions that have to be made.

In any case even if we did default to "virt" the user still
has to specify a CPU type, may well also want to provide
a GIC version (gicv3 being better than the default v2),
likely more RAM than the very small default, they need to provide
all the virtio devices, and so on and so on. So giving
them one option they no longer need to specify doesn't
really make it any easier IMHO.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-arm] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Andrea Bolognani]

On Sat, 2019-06-22 at 16:58 +0100, Peter Maydell wrote:
> On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <crosa@redhat.com> wrote:
> > You can consider me biased (I do consider myself), but trying to wear
> > the hat of a user first interacting with QEMU, I would expect a (any)
> > reasonably capable environment that can represent the given target.
> > That will probably be a different environment than the one I may need,
> > and I think that's fine.
> 
> I'm really not sure what you're trying to suggest here; maybe
> you could clarify? If you specify a target (ie a machine type),
> you get that machine type. If you don't specify a target, then
> we can't really guess what you were hoping to run and
> magically pick something that works.
> 
> The main problem here is that users expect "all the world is a PC"
> type behaviour, ie they can just provide qemu-system-arm or
> qemu-system-aarch64 with no command line arguments except
> a guest kernel (which is half the time something they found under
> a rock or extracted from some firmware image) or a guest CDROM
> image and have it boot, because that generally works for x86. It
> doesn't and can't work for Arm, because of the much greater
> diversity of machine types and the way that kernels are often
> only compiled to work on a specific subset of machines.
> Making the user specify a machine type means they do at least
> get prompted that the world is more complicated than they
> think it is and there are decisions that have to be made.
> 
> In any case even if we did default to "virt" the user still
> has to specify a CPU type, may well also want to provide
> a GIC version (gicv3 being better than the default v2),
> likely more RAM than the very small default, they need to provide
> all the virtio devices, and so on and so on. So giving
> them one option they no longer need to specify doesn't
> really make it any easier IMHO.

Additional note on GIC: most server-grade machines you can buy today
do *not* support GICv2, so you will need to opt-in to GICv3 if you
want your guest to even start.

More generally, as someone who has worked on supporting non-x86
guests in libvirt for the past few years, I can tell you from
experience that you're always going to need some arch-specific logic
to deal with the small (and not so small :) differences in behavior
between QEMU targets: as Peter correctly says, machine type is just
a single example among many.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [Qemu-arm] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Wainer dos Santos Moschetta]

On 06/24/2019 05:37 AM, Andrea Bolognani wrote:
> On Sat, 2019-06-22 at 16:58 +0100, Peter Maydell wrote:
>> On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <crosa@redhat.com> wrote:
>>> You can consider me biased (I do consider myself), but trying to wear
>>> the hat of a user first interacting with QEMU, I would expect a (any)
>>> reasonably capable environment that can represent the given target.
>>> That will probably be a different environment than the one I may need,
>>> and I think that's fine.
>> I'm really not sure what you're trying to suggest here; maybe
>> you could clarify? If you specify a target (ie a machine type),
>> you get that machine type. If you don't specify a target, then
>> we can't really guess what you were hoping to run and
>> magically pick something that works.
>>
>> The main problem here is that users expect "all the world is a PC"
>> type behaviour, ie they can just provide qemu-system-arm or
>> qemu-system-aarch64 with no command line arguments except
>> a guest kernel (which is half the time something they found under
>> a rock or extracted from some firmware image) or a guest CDROM
>> image and have it boot, because that generally works for x86. It
>> doesn't and can't work for Arm, because of the much greater
>> diversity of machine types and the way that kernels are often
>> only compiled to work on a specific subset of machines.
>> Making the user specify a machine type means they do at least
>> get prompted that the world is more complicated than they
>> think it is and there are decisions that have to be made.
>>
>> In any case even if we did default to "virt" the user still
>> has to specify a CPU type, may well also want to provide
>> a GIC version (gicv3 being better than the default v2),
>> likely more RAM than the very small default, they need to provide
>> all the virtio devices, and so on and so on. So giving
>> them one option they no longer need to specify doesn't
>> really make it any easier IMHO.
> Additional note on GIC: most server-grade machines you can buy today
> do *not* support GICv2, so you will need to opt-in to GICv3 if you
> want your guest to even start.
>
> More generally, as someone who has worked on supporting non-x86
> guests in libvirt for the past few years, I can tell you from
> experience that you're always going to need some arch-specific logic
> to deal with the small (and not so small :) differences in behavior
> between QEMU targets: as Peter correctly says, machine type is just
> a single example among many.
>

So NACK this patch. I will attempt to address the problem of broken 
acceptance tests on avocado_qemu side.

Thanks Peter, Cleber and Andrea for sharing your opinion.

- Wainer