| Message ID | 20190620222314.2670-1-wainersm@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC,v2] hw/arm/virt: makes virt a default machine type | expand |
On Thu, 20 Jun 2019 at 23:23, Wainer dos Santos Moschetta <wainersm@redhat.com> wrote: > I came across this when running the acceptance tests in an aarch64 host. > The arch-independent tests fail because, in general, they don't set a > machine type. In order to avoid treating arm targets as special cases > on avocado_qemu framework I prefered to attempt to promote virt as > default for ARM emulation. Moreover since it represents a generic hardware > and its used is broaden advised [1], I found it the right choice. Not providing a default machine type for Arm is a deliberate choice: there is no single right answer and the user has to decide what their preference is. We used to have a default machine type set, and it caused a lot of user confusion as they expected Arm to be like x86 where everything will run fine on the default machine type and it did not, which is why we switched to not having a default. thanks -- PMM
On Fri, Jun 21, 2019 at 11:33:10AM +0100, Peter Maydell wrote: > On Thu, 20 Jun 2019 at 23:23, Wainer dos Santos Moschetta > <wainersm@redhat.com> wrote: > > I came across this when running the acceptance tests in an aarch64 host. > > The arch-independent tests fail because, in general, they don't set a > > machine type. In order to avoid treating arm targets as special cases > > on avocado_qemu framework I prefered to attempt to promote virt as > > default for ARM emulation. Moreover since it represents a generic hardware > > and its used is broaden advised [1], I found it the right choice. > > Not providing a default machine type for Arm is a deliberate > choice: there is no single right answer and the user has > to decide what their preference is. We used to have a default > machine type set, and it caused a lot of user confusion as > they expected Arm to be like x86 where everything will run > fine on the default machine type and it did not, which is > why we switched to not having a default. > > thanks > -- PMM 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. 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. Now on the functional testing side, this means less code adjusting to the specifics of each target, and overall, more test code that could be reused across different targets. I believe the same to be true for management layer code. Anyway, it'd be nice to just double check if keeping things as they are is in this specific aspect is a firm yes. If so, tests (and management layers) will (continue to) have to adapat. Best, - Cleber.
On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <crosa@redhat.com> 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. thanks -- PMM
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.
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
diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 431e2900fd..2f8aa2bfb7 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -74,6 +74,7 @@ mc->desc = "QEMU " # major "." # minor " ARM Virtual Machine"; \ if (latest) { \ mc->alias = "virt"; \ + mc->is_default = 1; \ } \ } \ static const TypeInfo machvirt_##major##_##minor##_info = { \
Peter, Cleber, Re-sending this email because I forgot to copy the mailing listing. Sorry. Original message below. == Hi Peter et al., I came across this when running the acceptance tests in an aarch64 host. The arch-independent tests fail because, in general, they don't set a machine type. In order to avoid treating arm targets as special cases on avocado_qemu framework I prefered to attempt to promote virt as default for ARM emulation. Moreover since it represents a generic hardware and its used is broaden advised [1], I found it the right choice. Maybe that topic was discussed already but I didn't find any reference on either the mailing list and git logs. It is also true that I am an ignorant on ARM platform, thus I might be missing something. Those explain why I send this patch as RFC. [1] https://wiki.qemu.org/Documentation/Platforms/ARM Thanks, Wainer -- >8 -- Currently none arm target has a default machine type, unlike others as x86_64 and ppc64. The 'virt' (alias) type represents a generic ARM hardware, so let's specify it the default machine for ARM emulation. Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> --- hw/arm/virt.c | 1 + 1 file changed, 1 insertion(+)