On Sat, 2019-06-22 at 16:58 +0100, Peter Maydell wrote:
On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <address@hidden> 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.