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