Commit 26cfb1a3cd39 introduced a list of preferred machine types,
which are meant to reflect QEMU's per-architecture historical
defaults and shield libvirt users from any changes in that area.
Arm architectures, however, never had a default machine type
associated with them, so if no machine type is requested by the
user we should just go through the usual path of picking the
first one reported by the 'query-machines' QMP command instead
of using integratorcp straight away.
Reported-by: Kashyap Chamarthy <kchamart@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
src/qemu/qemu_capabilities.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index fde27010e4..09980467b1 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2200,10 +2200,10 @@ static const char *preferredMachines[] =
NULL, /* VIR_ARCH_NONE (not a real arch :) */
"clipper", /* VIR_ARCH_ALPHA */
NULL, /* VIR_ARCH_ARMV6L (no QEMU impl) */
- "integratorcp", /* VIR_ARCH_ARMV7L */
- "integratorcp", /* VIR_ARCH_ARMV7B */
+ NULL, /* VIR_ARCH_ARMV7L (no default machine type) */
+ NULL, /* VIR_ARCH_ARMV7B (no default machine type) */
- "integratorcp", /* VIR_ARCH_AARCH64 */
+ NULL, /* VIR_ARCH_AARCH64 (no default machine type) */
"axis-dev88", /* VIR_ARCH_CRIS */
"pc", /* VIR_ARCH_I686 */
NULL, /* VIR_ARCH_ITANIUM (doesn't exist in QEMU any more) */
--
2.19.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Nov 26, 2018 at 01:21:32PM +0100, Andrea Bolognani wrote: > Commit 26cfb1a3cd39 introduced a list of preferred machine types, > which are meant to reflect QEMU's per-architecture historical > defaults and shield libvirt users from any changes in that area. > > Arm architectures, however, never had a default machine type > associated with them, so if no machine type is requested by the > user we should just go through the usual path of picking the > first one reported by the 'query-machines' QMP command instead > of using integratorcp straight away. > > Reported-by: Kashyap Chamarthy <kchamart@redhat.com> > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > src/qemu/qemu_capabilities.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Thanks. FWIW: Reviewed-by Kashyap Chamarthy <kchamart@redhat.com> > + NULL, /* VIR_ARCH_AARCH64 (no default machine type) */ > "axis-dev88", /* VIR_ARCH_CRIS */ > "pc", /* VIR_ARCH_I686 */ > NULL, /* VIR_ARCH_ITANIUM (doesn't exist in QEMU any more) */ > -- > 2.19.1 > -- /kashyap -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Nov 26, 2018 at 01:21:32PM +0100, Andrea Bolognani wrote: > Commit 26cfb1a3cd39 introduced a list of preferred machine types, > which are meant to reflect QEMU's per-architecture historical > defaults and shield libvirt users from any changes in that area. > > Arm architectures, however, never had a default machine type > associated with them, so if no machine type is requested by the > user we should just go through the usual path of picking the > first one reported by the 'query-machines' QMP command instead > of using integratorcp straight away. > > Reported-by: Kashyap Chamarthy <kchamart@redhat.com> > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > src/qemu/qemu_capabilities.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) NACK, this is incorrect and breaking historical libvirt behaviour. When QEMU does not report any default machine type for an architecture, libvirt would pick the first machine type it found. This is why "integratorcp" must be listed here. > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index fde27010e4..09980467b1 100644 > --- a/src/qemu/qemu_capabilities.c > +++ b/src/qemu/qemu_capabilities.c > @@ -2200,10 +2200,10 @@ static const char *preferredMachines[] = > NULL, /* VIR_ARCH_NONE (not a real arch :) */ > "clipper", /* VIR_ARCH_ALPHA */ > NULL, /* VIR_ARCH_ARMV6L (no QEMU impl) */ > - "integratorcp", /* VIR_ARCH_ARMV7L */ > - "integratorcp", /* VIR_ARCH_ARMV7B */ > + NULL, /* VIR_ARCH_ARMV7L (no default machine type) */ > + NULL, /* VIR_ARCH_ARMV7B (no default machine type) */ > > - "integratorcp", /* VIR_ARCH_AARCH64 */ > + NULL, /* VIR_ARCH_AARCH64 (no default machine type) */ > "axis-dev88", /* VIR_ARCH_CRIS */ > "pc", /* VIR_ARCH_I686 */ > NULL, /* VIR_ARCH_ITANIUM (doesn't exist in QEMU any more) */ > -- > 2.19.1 > Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2018-11-27 at 15:28 +0000, Daniel P. Berrangé wrote: > On Mon, Nov 26, 2018 at 01:21:32PM +0100, Andrea Bolognani wrote: > > Commit 26cfb1a3cd39 introduced a list of preferred machine types, > > which are meant to reflect QEMU's per-architecture historical > > defaults and shield libvirt users from any changes in that area. > > > > Arm architectures, however, never had a default machine type > > associated with them, so if no machine type is requested by the > > user we should just go through the usual path of picking the > > first one reported by the 'query-machines' QMP command instead > > of using integratorcp straight away. > > NACK, this is incorrect and breaking historical libvirt behaviour. > > When QEMU does not report any default machine type for an > architecture, libvirt would pick the first machine type > it found. This is why "integratorcp" must be listed here. I suspected as much after initially discussing the issue, hence why I CC'd you when posting. Looks like that was a good call! :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.