Re: [Qemu-devel] [Qemu-arm] [RFC v2 PATCH] hw/arm/virt: makes virt a default machine type

[Wainer dos Santos Moschetta <wainersm@redhat.com>]

On 06/24/2019 05:37 AM, Andrea Bolognani wrote:
> On Sat, 2019-06-22 at 16:58 +0100, Peter Maydell wrote:
>> On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <crosa@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.
>

So NACK this patch. I will attempt to address the problem of broken 
acceptance tests on avocado_qemu side.

Thanks Peter, Cleber and Andrea for sharing your opinion.

- Wainer