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 <address@hidden> 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