[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine
Re: [Qemu-arm] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type
Sat, 22 Jun 2019 16:58:25 +0100
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.