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

[Cleber Rosa <crosa@redhat.com>]

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.