Re: [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 <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.

-- 
Andrea Bolognani / Red Hat / Virtualization