From nobody Thu May 2 02:57:01 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1533644580001112.37584624908709; Tue, 7 Aug 2018 05:23:00 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCCE0308FB9A; Tue, 7 Aug 2018 12:22:57 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D9BF5DD65; Tue, 7 Aug 2018 12:22:57 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 0A55A1800B69; Tue, 7 Aug 2018 12:22:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w77CMtoM023234 for ; Tue, 7 Aug 2018 08:22:55 -0400 Received: by smtp.corp.redhat.com (Postfix) id 81D0A1C5BF; Tue, 7 Aug 2018 12:22:55 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.33.36.66]) by smtp.corp.redhat.com (Postfix) with ESMTP id 983711C5B7; Tue, 7 Aug 2018 12:22:52 +0000 (UTC) From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Tue, 7 Aug 2018 13:22:49 +0100 Message-Id: <20180807122249.7088-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] qemu: ensure default machine types don't change if QEMU changes X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Tue, 07 Aug 2018 12:22:58 +0000 (UTC) X-ZohoMail: RDMRC_0 RSF_0 Z_629925259 SPT_0 It is increasingly likely that some distro is going to change the default "x86" machine type in QEMU from "pc" to "q35". This will certainly break existing applications which write their XML on the assumption that it is using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCIe instead of PCI which changes the topology radically. Libvirt promises to isolate applications from hypervisor changes that may cause incompatibilities, so we must ensure that we always use the "pc" machine type if it is available. Only use QEMU's own reported default machine type if "pc" does not exist. This issue is not x86-only, other arches are liable t change their default machine, while some arches don't report any default at all causing libvirt to pick the first machine in the list. Thus to guarantee stability to applications, declare a preferred default machine for all architectures we currently support with QEMU. Note this change assumes there will always be a "pc" alias as long as a versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX" machine type but not provide the "pc" alias, it is too hard to decide which to default so. Versioned machine types are supposed to be considered opaque strings, so we can't apply any sensible ordering ourselves and QEMU isn't reporting the list of machines in any sensible ordering itself. Signed-off-by: Daniel P. Berrang=C3=A9 --- src/qemu/qemu_capabilities.c | 79 ++++++++++++++++++++++++++++++++++-- 1 file changed, 76 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 0fb800589a..045e2bd489 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2233,6 +2233,61 @@ virQEMUCapsProbeQMPDevices(virQEMUCapsPtr qemuCaps, } =20 =20 +/* Historically QEMU x86 targets defaulted to 'pc' machine type but + * in future x86_64 might switch 'q35'. Such a change is considered + * an ABI break from libvirt's POV. Other QEMU targets may not declare + * a default macine at all, causing libvirt to use the first reported + * machinbe in the list. + * + * Here we record a preferred default machine for all arches, so + * that we're not vulnerable to changes in QEMU defaults or machine + * list ordering. + */ +static const char *preferredMachines[VIR_ARCH_LAST] =3D +{ + [VIR_ARCH_ALPHA] =3D "clipper", + [VIR_ARCH_ARMV6L] =3D NULL, /* No QEMU impl */ + [VIR_ARCH_ARMV7L] =3D "integratorcp", + [VIR_ARCH_ARMV7B] =3D "integratorcp", + + [VIR_ARCH_AARCH64] =3D "integratorcp", + [VIR_ARCH_CRIS] =3D "axis-dev88", + [VIR_ARCH_I686] =3D "pc", + [VIR_ARCH_ITANIUM] =3D NULL, /* doesn't exist in QEMU any more */ + [VIR_ARCH_LM32] =3D "lm32-evr", + + [VIR_ARCH_M68K] =3D "mcf5208evb", + [VIR_ARCH_MICROBLAZE] =3D "petalogix-s3adsp1800", + [VIR_ARCH_MICROBLAZEEL] =3D "petalogix-s3adsp1800", + [VIR_ARCH_MIPS] =3D "malta", + [VIR_ARCH_MIPSEL] =3D "malta", + + [VIR_ARCH_MIPS64] =3D "malta", + [VIR_ARCH_MIPS64EL] =3D "malta", + [VIR_ARCH_OR32] =3D "or1k-sim", + [VIR_ARCH_PARISC] =3D NULL, /* No QEMU impl */ + [VIR_ARCH_PARISC64] =3D NULL, /* No QEMU impl */ + + [VIR_ARCH_PPC] =3D "g3beige", + [VIR_ARCH_PPCLE] =3D "g3beige", + [VIR_ARCH_PPC64] =3D "pseries", + [VIR_ARCH_PPC64LE] =3D "pseries", + [VIR_ARCH_PPCEMB] =3D "bamboo", + + [VIR_ARCH_S390] =3D NULL, /* No QEMU impl*/ + [VIR_ARCH_S390X] =3D "s390-ccw-virtio", + [VIR_ARCH_SH4] =3D "shix", + [VIR_ARCH_SH4EB] =3D "shix", + [VIR_ARCH_SPARC] =3D "SS-5", + + [VIR_ARCH_SPARC64] =3D "sun4u", + [VIR_ARCH_UNICORE32] =3D "puv3", + [VIR_ARCH_X86_64] =3D "pc", + [VIR_ARCH_XTENSA] =3D "sim", + [VIR_ARCH_XTENSAEB] =3D "sim", + +}; + static int virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, qemuMonitorPtr mon) @@ -2241,7 +2296,9 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCa= ps, int nmachines =3D 0; int ret =3D -1; size_t i; - size_t defIdx =3D 0; + ssize_t defIdx =3D -1; + ssize_t preferredIdx =3D -1; + const char *preferredMachine =3D preferredMachines[qemuCaps->arch]; =20 if ((nmachines =3D qemuMonitorGetMachines(mon, &machines)) < 0) return -1; @@ -2263,12 +2320,28 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemu= Caps, mach->maxCpus =3D machines[i]->maxCpus; mach->hotplugCpus =3D machines[i]->hotplugCpus; =20 + if (preferredMachine && + (STREQ_NULLABLE(mach->alias, preferredMachine) || + STREQ(mach->name, preferredMachine))) + preferredIdx =3D qemuCaps->nmachineTypes - 1; + if (machines[i]->isDefault) defIdx =3D qemuCaps->nmachineTypes - 1; } =20 - if (defIdx) - virQEMUCapsSetDefaultMachine(qemuCaps, defIdx); + /* + * We'll prefer to use our own historical default machine + * to avoid mgmt apps seeing semantics changes when QEMU + * alters it defaults. + * + * Our preferred pmachine might have been compiled out of + * QEMU at build time though, so we still fallback to honouring + * QEMU's reported default in that case + */ + if (preferredIdx =3D=3D -1) + preferredIdx =3D defIdx; + if (preferredIdx !=3D -1) + virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx); =20 ret =3D 0; =20 --=20 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list