- Devel - libvirt List Archives

[libvirt] [PATCH 0/9] iSCSI fixes and improvements
by Pavel Hrdina 08 Aug '18

08 Aug '18

Pavel Hrdina (9): docs: fix iscsi-direct XML example conf: properly translate iscsi-direct storage pool conf: rename and move virStoragePoolSourceInitiatorAttr util: introduce virStorageSourceInitiator functions conf: use virStorageSourceInitiator functions docs: move storage initiator def into storagecommon.rng conf: introduce initiator IQN support for domain disks tests: introduce qemu disk-network-iscsi-modern test cases qemu: add support for domain disk initiator IQN docs/formatdomain.html.in | 20 +++++ docs/schemas/domaincommon.rng | 3 + docs/schemas/storagecommon.rng | 11 +++ docs/schemas/storagepool.rng | 11 --- docs/storage.html.in | 6 +- src/conf/domain_conf.c | 71 +++++++++++++----- src/conf/storage_conf.c | 16 ++-- src/conf/storage_conf.h | 7 +- src/qemu/qemu_block.c | 2 + src/qemu/qemu_domain.c | 9 +++ src/util/virstoragefile.c | 39 ++++++++++ src/util/virstoragefile.h | 23 ++++++ .../disk-network-iscsi-modern.args | 58 ++++++++++++++ .../disk-network-iscsi-modern.xml | 75 +++++++++++++++++++ tests/qemuxml2argvtest.c | 4 + 15 files changed, 306 insertions(+), 49 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-network-iscsi-modern.args create mode 100644 tests/qemuxml2argvdata/disk-network-iscsi-modern.xml -- 2.17.1

3 19

[libvirt] [PATCH] qemu: ensure default machine types don't change if QEMU changes
by Daniel P. Berrangé 08 Aug '18

08 Aug '18

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é <berrange(a)redhat.com> --- 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, } +/* 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] = +{ + [VIR_ARCH_ALPHA] = "clipper", + [VIR_ARCH_ARMV6L] = NULL, /* No QEMU impl */ + [VIR_ARCH_ARMV7L] = "integratorcp", + [VIR_ARCH_ARMV7B] = "integratorcp", + + [VIR_ARCH_AARCH64] = "integratorcp", + [VIR_ARCH_CRIS] = "axis-dev88", + [VIR_ARCH_I686] = "pc", + [VIR_ARCH_ITANIUM] = NULL, /* doesn't exist in QEMU any more */ + [VIR_ARCH_LM32] = "lm32-evr", + + [VIR_ARCH_M68K] = "mcf5208evb", + [VIR_ARCH_MICROBLAZE] = "petalogix-s3adsp1800", + [VIR_ARCH_MICROBLAZEEL] = "petalogix-s3adsp1800", + [VIR_ARCH_MIPS] = "malta", + [VIR_ARCH_MIPSEL] = "malta", + + [VIR_ARCH_MIPS64] = "malta", + [VIR_ARCH_MIPS64EL] = "malta", + [VIR_ARCH_OR32] = "or1k-sim", + [VIR_ARCH_PARISC] = NULL, /* No QEMU impl */ + [VIR_ARCH_PARISC64] = NULL, /* No QEMU impl */ + + [VIR_ARCH_PPC] = "g3beige", + [VIR_ARCH_PPCLE] = "g3beige", + [VIR_ARCH_PPC64] = "pseries", + [VIR_ARCH_PPC64LE] = "pseries", + [VIR_ARCH_PPCEMB] = "bamboo", + + [VIR_ARCH_S390] = NULL, /* No QEMU impl*/ + [VIR_ARCH_S390X] = "s390-ccw-virtio", + [VIR_ARCH_SH4] = "shix", + [VIR_ARCH_SH4EB] = "shix", + [VIR_ARCH_SPARC] = "SS-5", + + [VIR_ARCH_SPARC64] = "sun4u", + [VIR_ARCH_UNICORE32] = "puv3", + [VIR_ARCH_X86_64] = "pc", + [VIR_ARCH_XTENSA] = "sim", + [VIR_ARCH_XTENSAEB] = "sim", + +}; + static int virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, qemuMonitorPtr mon) @@ -2241,7 +2296,9 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, int nmachines = 0; int ret = -1; size_t i; - size_t defIdx = 0; + ssize_t defIdx = -1; + ssize_t preferredIdx = -1; + const char *preferredMachine = preferredMachines[qemuCaps->arch]; if ((nmachines = qemuMonitorGetMachines(mon, &machines)) < 0) return -1; @@ -2263,12 +2320,28 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, mach->maxCpus = machines[i]->maxCpus; mach->hotplugCpus = machines[i]->hotplugCpus; + if (preferredMachine && + (STREQ_NULLABLE(mach->alias, preferredMachine) || + STREQ(mach->name, preferredMachine))) + preferredIdx = qemuCaps->nmachineTypes - 1; + if (machines[i]->isDefault) defIdx = qemuCaps->nmachineTypes - 1; } - 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 == -1) + preferredIdx = defIdx; + if (preferredIdx != -1) + virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx); ret = 0; -- 2.17.1

2 7

[libvirt] [PATCH v3] conf: virDomainDefValidateInternal prohibit some characters in shmem name
by Simon Kobyda 08 Aug '18

08 Aug '18

Validate that the provided XML shmem name is not directory specific "." or ".." names as well as ensuring that there is no path separator '/' in the name. https://bugzilla.redhat.com/show_bug.cgi?id=1192400 Signed-off-by: Simon Kobyda <skobyda(a)redhat.com> --- Changes in v3: - moved the functionality to virDomainDeviceDefValidateInternal - documented changes in docs/formatdomain.html.in docs/formatdomain.html.in | 4 +++- src/conf/domain_conf.c | 29 ++++++++++++++++++++++++++++- 2 files changed, 31 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index a3afe137bf..f18ca6fc64 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -8017,7 +8017,9 @@ qemu-kvm -net nic,model=? /dev/null <dt><code>shmem</code></dt> <dd> The <code>shmem</code> element has one mandatory attribute, - <code>name</code> to identify the shared memory. + <code>name</code> to identify the shared memory. This attribute cannot + be directory specific to <code>.</code> or <code>..</code> as well as + it cannot involve path separator <code>/</code>. </dd> <dt><code>model</code></dt> <dd> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 7ab2953d83..415c03c56f 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -5696,6 +5696,31 @@ virDomainVsockDefValidate(const virDomainVsockDef *vsock) } +static int +virDomainShmemDefValidate(const virDomainShmemDef *shmem) +{ + if (strchr(shmem->name, '/')) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("shmem name cannot include '/' character")); + return -1; + } + + if (STREQ(shmem->name, ".")) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("shmem name cannot be equal to '.'")); + return -1; + } + + if (STREQ(shmem->name, "..")) { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("shmem name cannot be equal to '..'")); + return -1; + } + + return 0; +} + + static int virDomainDeviceDefValidateInternal(const virDomainDeviceDef *dev, const virDomainDef *def) @@ -5734,6 +5759,9 @@ virDomainDeviceDefValidateInternal(const virDomainDeviceDef *dev, case VIR_DOMAIN_DEVICE_VSOCK: return virDomainVsockDefValidate(dev->data.vsock); + case VIR_DOMAIN_DEVICE_SHMEM: + return virDomainShmemDefValidate(dev->data.shmem); + case VIR_DOMAIN_DEVICE_LEASE: case VIR_DOMAIN_DEVICE_FS: case VIR_DOMAIN_DEVICE_INPUT: @@ -5743,7 +5771,6 @@ virDomainDeviceDefValidateInternal(const virDomainDeviceDef *dev, case VIR_DOMAIN_DEVICE_HUB: case VIR_DOMAIN_DEVICE_MEMBALLOON: case VIR_DOMAIN_DEVICE_NVRAM: - case VIR_DOMAIN_DEVICE_SHMEM: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: case VIR_DOMAIN_DEVICE_IOMMU: -- 2.17.1

2 1

[libvirt] [PATCH 0/2] Fix the non-linux platform build after recent VIR_AUTOPTR patches
by Erik Skultety 08 Aug '18

08 Aug '18

There were some complaints about an unused variable (patch 1) and unused static functions which are defined by the VIR_DEFINE_AUTOPTR_FUNC macro (patch 2). Successful Travis build: https://travis-ci.org/eskultety/libvirt/builds/413187470 MinGW wasn't affected by the recent VIR_AUTOPTR series: https://ci.centos.org/view/libvirt/job/libvirt-master-build-mingw64/330/ *NOT* pushing under the build breaker in case someone wants to have a look. Erik Skultety (2): util: virnetdevopenvswitch: Drop an unused variable @ovs_timeout Fix the build on non-linux platforms after VIR_AUTOPTR related changes src/util/virnetdev.c | 3 +-- src/util/virnetdevopenvswitch.c | 1 - src/util/virnetlink.c | 6 ++---- 3 files changed, 3 insertions(+), 7 deletions(-) -- 2.14.4

3 6

[libvirt] [PATCH v3 0/3] qemu: Support vhost-vsock-ccw
by Boris Fiuczynski 08 Aug '18

08 Aug '18

Support the vhost-vsock-ccw device on S390. Since v2 - instead of reusing CAPS_LATEST adding CAPS_ARCH_LATEST (Peter Krempa) Since v1 - adjusted vsock command line generation (Ján Tomko) - added CAPS_LATEST test coverage to s390 (Ján Tomko) - adjusted new vsock tests to use CAPS_LATEST Bjoern Walk (1): tests: qemuxml2argv: add CAPS_ARCH_LATEST macro Boris Fiuczynski (2): qemu: Add ccw support for vhost-vsock news: Update for vhost-vsock-ccw support docs/news.xml | 8 +++++ src/qemu/qemu_command.c | 8 +++-- src/qemu/qemu_domain.c | 10 ++++-- src/qemu/qemu_domain_address.c | 7 +++- .../vhost-vsock-ccw-auto.s390x-latest.args | 32 ++++++++++++++++++ .../qemuxml2argvdata/vhost-vsock-ccw-auto.xml | 25 ++++++++++++++ .../vhost-vsock-ccw.s390x-latest.args | 32 ++++++++++++++++++ tests/qemuxml2argvdata/vhost-vsock-ccw.xml | 32 ++++++++++++++++++ tests/qemuxml2argvtest.c | 33 ++++++++++++++----- .../vhost-vsock-ccw-auto.xml | 32 ++++++++++++++++++ tests/qemuxml2xmloutdata/vhost-vsock-ccw.xml | 1 + tests/qemuxml2xmltest.c | 5 +++ 12 files changed, 212 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw-auto.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw-auto.xml create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw.s390x-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock-ccw.xml create mode 100644 tests/qemuxml2xmloutdata/vhost-vsock-ccw-auto.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-vsock-ccw.xml -- 2.17.0

2 5

[libvirt] [PATCH v2 00/35] use GNU C's cleanup attribute in src/util (batch III)
by Sukrit Bhatnagar 08 Aug '18

08 Aug '18

This third series of patches also modifies a few files in src/util to use VIR_AUTOFREE and VIR_AUTOPTR for automatic freeing of memory and get rid of some VIR_FREE macro invocations and *Free function calls. Sukrit Bhatnagar (35): util: iscsi: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: iscsi: use VIR_AUTOPTR for aggregate types util: netlink: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netlink: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netlink: use VIR_AUTOPTR for aggregate types util: netdevbridge: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevbridge: use VIR_AUTOPTR for aggregate types util: macaddr: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdev: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdev: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdev: use VIR_AUTOPTR for aggregate types util: socketaddr: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: socketaddr: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: socketaddr: use VIR_AUTOPTR for aggregate types util: netdevip: define virNetDevIPAddrFree for use with cleanup macros util: netdevip: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdevip: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevip: use VIR_AUTOPTR for aggregate types util: netdevmacvlan: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdevmacvlan: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevmacvlan: use VIR_AUTOPTR for aggregate types util: netdevopenvswitch: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevopenvswitch: use VIR_AUTOPTR for aggregate types util: netdevtap: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevveth: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevveth: use VIR_AUTOPTR for aggregate types util: numa: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: numa: use VIR_AUTOPTR for aggregate types util: perf: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: perf: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: pidfile: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: process: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: process: use VIR_AUTOPTR for aggregate types util: qemu: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: qemu: use VIR_AUTOPTR for aggregate types src/util/viriscsi.c | 140 ++++------ src/util/virmacaddr.c | 6 + src/util/virmacaddr.h | 4 + src/util/virnetdev.c | 604 ++++++++++++++++------------------------ src/util/virnetdev.h | 4 + src/util/virnetdevbridge.c | 81 ++---- src/util/virnetdevip.c | 227 ++++++--------- src/util/virnetdevip.h | 5 + src/util/virnetdevmacvlan.c | 22 +- src/util/virnetdevopenvswitch.c | 98 +++---- src/util/virnetdevtap.c | 11 +- src/util/virnetdevveth.c | 32 +-- src/util/virnetlink.c | 118 ++++---- src/util/virnetlink.h | 5 + src/util/virnuma.c | 103 +++---- src/util/virperf.c | 20 +- src/util/virperf.h | 8 +- src/util/virpidfile.c | 186 ++++--------- src/util/virprocess.c | 58 ++-- src/util/virqemu.c | 31 +-- src/util/virsocketaddr.c | 113 ++++---- src/util/virsocketaddr.h | 9 +- 22 files changed, 730 insertions(+), 1155 deletions(-) -- 1.8.3.1

2 36

Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
by Alex Williamson 07 Aug '18

07 Aug '18

On Mon, 9 Apr 2018 12:35:10 +0200 Gerd Hoffmann <kraxel(a)redhat.com> wrote: > This little series adds three drivers, for demo-ing and testing vfio > display interface code. There is one mdev device for each interface > type (mdpy.ko for region and mbochs.ko for dmabuf). Erik Skultety brought up a good question today regarding how libvirt is meant to handle these different flavors of display interfaces and knowing whether a given mdev device has display support at all. It seems that we cannot simply use the default display=auto because libvirt needs to specifically configure gl support for a dmabuf type interface versus not having such a requirement for a region interface, perhaps even removing the emulated graphics in some cases (though I don't think we have boot graphics through either solution yet). Additionally, GVT-g seems to need the x-igd-opregion support enabled(?), which is a non-starter for libvirt as it's an experimental option! Currently the only way to determine display support is through the VFIO_DEVICE_QUERY_GFX_PLANE ioctl, but for libvirt to probe that on their own they'd need to get to the point where they could open the vfio device and perform the ioctl. That means opening a vfio container, adding the group, setting the iommu type, and getting the device. I was initially a bit appalled at asking libvirt to do that, but the alternative is to put this information in sysfs, but doing that we risk that we need to describe every nuance of the mdev device through sysfs and it becomes a dumping ground for every possible feature an mdev device might have. So I was ready to return and suggest that maybe libvirt should probe the device to know about these ancillary configuration details, but then I remembered that both mdev vGPU vendors had external dependencies to even allow probing the device. KVMGT will fail to open the device if it's not associated with an instance of KVM and NVIDIA vGPU, I believe, will fail if the vGPU manager process cannot find the QEMU instance to extract the VM UUID. (Both of these were bad ideas) Therefore, how can libvirt know if a given mdev device supports a display and which type of display it supports, and potentially which vendor specific options might be required to further enable that display (if they weren't experimental)? A terrible solution would be that libvirt hard codes that NVIDIA works with regions and Intel works with dmabufs, but even then there's a backwards and forwards compatibility problem, that libvirt needs to support older kernels and drivers where display support is not present and newer drivers where perhaps Intel is now doing regions and NVIDIA is supporting dmabuf, so it cannot simply be assumed based on the vendor. The only solution I see down that path would be identifying specific {vendor,type} pairs that support a predefined display type, but that's just absurd to think that vendors would rev their mdev types to expose this and that libvirt would keep a database mapping types to features. We also have the name and description attributes, but these are currently free form, so libvirt rightfully ignores them entirely. I don't know if we could create a defined feature string within those free form strings. Otherwise, it seems we have no choice but to dive into the pool of exposing such features via sysfs and we'll need to be vigilant of feature creep or vendor specific features (ex. we're not adding a feature to indicate an opregion requirement). How should we do this? Perhaps a bar we can set is that if a feature cannot be discovered through a standard vfio API, then it is not suitable for this sysfs API. Such things can be described via our existing mdev vendor specific attribute interface. We currently have this sysfs interface: mdev_supported_types/ |-- $VENDOR_TYPE | |-- available_instances | |-- create | |-- description | |-- device_api | |-- devices | `-- name ioctls for vfio devices which only provide information include: VFIO_DEVICE_GET_INFO VFIO_DEVICE_GET_REGION_INFO VFIO_DEVICE_GET_IRQ_INFO VFIO_DEVICE_GET_PCI_HOT_RESET_INFO VFIO_DEVICE_QUERY_GFX_PLANE We don't need to support all of these initially, but here's a starting idea for what this may look like in sysfs: $VENDOR_TYPE/ |-- available_instances |-- create |-- description |-- device_api |-- devices |-- name `-- vfio-pci `-- device |-- gfx_plane | |-- dmabuf | `-- region |-- irqs | |-- 0 | | |-- count | | `-- flags | `-- 1 | |-- count | `-- flags `-- regions |-- 0 | |-- flags | |-- offset | `-- size `-- 3 |-- flags |-- offset `-- size The existing device_api file reports "vfio-pci", so we base the device API info in a directory named vfio-pci. We're specifically exposing device information, so we have a device directory. We have a GFX_PLANE query ioctl, so we have a gfx_plane sub-directory. I imagine the dmabuf and region files here expose either Y/N or 1/0. I continue on the example with how we might expose irqs and regions, but even with regions we can bury down into how is sparse mmap exposed, how are device specific regions described, etc. Filling this in to completion without a specific userspace need to expose the information is just an exercise in bloating the kernel. That almost begins to look reasonable, but then we can only expose this for mdev devices, what if we were to hack a back door into a directly assigned GPU that tracks the location of active display in the framebuffer and implement the GFX_PLANE interface for that? We have no sysfs representation for either the template or the actual device for anything other than mdev. This inconsistency with physically assigned devices has been one of my arguments against enhancing mdev sysfs. Thanks to anyone still reading this. Ideas how we might help libvirt fill this information void so that they can actually configure a VM with a display device? Thanks, Alex

11 31

[libvirt] [PATCH] qemu: ensure "pc" machine is always used as default if available
by Daniel P. Berrangé 07 Aug '18

07 Aug '18

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 its using a "pc" machine by default. For example they'll lack a IDE CDROM and get PCI-X instad 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. 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é <berrange(a)redhat.com> --- src/qemu/qemu_capabilities.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 0fb800589a..9eb58afef3 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2242,6 +2242,17 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, int ret = -1; size_t i; size_t defIdx = 0; + ssize_t preferredIdx = -1; + const char *preferredAlias = NULL; + + /* Historically QEMU defaulted to 'pc' machine type but in + * future might switch 'q35'. Such a change is considered + * an ABI break from lbivirt's POV, so we must be sure to + * keep 'pc' as default machine no matter what QEMU says. + */ + if (qemuCaps->arch == VIR_ARCH_X86_64 || + qemuCaps->arch == VIR_ARCH_I686) + preferredAlias = "pc"; if ((nmachines = qemuMonitorGetMachines(mon, &machines)) < 0) return -1; @@ -2263,12 +2274,16 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, mach->maxCpus = machines[i]->maxCpus; mach->hotplugCpus = machines[i]->hotplugCpus; + if (STREQ_NULLABLE(mach->alias, preferredAlias)) + preferredIdx = qemuCaps->nmachineTypes - 1; + if (machines[i]->isDefault) defIdx = qemuCaps->nmachineTypes - 1; } - if (defIdx) - virQEMUCapsSetDefaultMachine(qemuCaps, defIdx); + if (preferredIdx == -1) + preferredIdx = defIdx; + virQEMUCapsSetDefaultMachine(qemuCaps, preferredIdx); ret = 0; -- 2.17.1

4 12

[libvirt] [PATCH libvirt v2 0/9] Fix virConnectRegisterCloseCallback and get rid of global variables
by Marc Hartmayer 07 Aug '18

07 Aug '18

The first part of this patch series fixes the behavior of virConnectRegisterCloseCallback and converts the testDriver to virObjectLockable. The subsequent patches remove the need to have the global variables 'qemuProgram' and 'remoteProgram' in libvirtd.[ch]. They only work in combination with the fixed behavior of virConnectRegisterCloseCallback. Changelog: + v1->v2: - Removed accepted patches - Removed NACKed patches - Added r-b to patch 5 - Worked in comments - Rebased - Added patches 7-9 Marc Hartmayer (9): virConnectRegisterCloseCallback: Cleanup 'opaque' if there is no connectRegisterCloseCallback test: Convert testDriver to virObjectLockable remote: Add the information which program has to be used to daemonClientEventCallback remote: Use domainClientEventCallbacks for remoteReplayConnectionClosedEvent rpc: Introduce virNetServerGetProgramLocked helper function remote/rpc: Use virNetServerGetProgram() to determine the program rpc: use the return value of virObjectRef directly remote: remove ATTRIBUTE_UNUSED when attribute is actually used remote: shrink the critical sections src/libvirt-host.c | 10 +- src/libvirt_remote.syms | 1 + src/remote/remote_daemon.c | 4 +- src/remote/remote_daemon.h | 3 - src/remote/remote_daemon_dispatch.c | 264 +++++++++++++++++++++++------------- src/rpc/gendispatch.pl | 6 + src/rpc/virnetserver.c | 57 ++++++-- src/rpc/virnetserver.h | 2 + src/test/test_driver.c | 200 ++++++++++++--------------- 9 files changed, 328 insertions(+), 219 deletions(-) -- 2.13.4

4 34

[libvirt] [PATCH v1 00/32] use GNU C's cleanup attribute in src/util (batch III)
by Sukrit Bhatnagar 07 Aug '18

07 Aug '18

This third series of patches also modifies a few files in src/util to use VIR_AUTOFREE and VIR_AUTOPTR for automatic freeing of memory and get rid of some VIR_FREE macro invocations and *Free function calls. Sukrit Bhatnagar (32): util: iscsi: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: iscsi: use VIR_AUTOPTR for aggregate types util: netdevbridge: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: macaddr: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdev: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdev: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdev: use VIR_AUTOPTR for aggregate types util: socketaddr: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: socketaddr: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: socketaddr: use VIR_AUTOPTR for aggregate types util: netdevip: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdevip: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevip: use VIR_AUTOPTR for aggregate types util: netdevmacvlan: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netdevmacvlan: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevmacvlan: use VIR_AUTOPTR for aggregate types util: netdevopenvswitch: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevopenvswitch: use VIR_AUTOPTR for aggregate types util: netdevtap: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevveth: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: netdevveth: use VIR_AUTOPTR for aggregate types util: netlink: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: netlink: use VIR_AUTOPTR for aggregate types util: numa: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: numa: use VIR_AUTOPTR for aggregate types util: perf: define cleanup function using VIR_DEFINE_AUTOPTR_FUNC util: perf: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: pidfile: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: process: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: process: use VIR_AUTOPTR for aggregate types util: qemu: use VIR_AUTOFREE instead of VIR_FREE for scalar types util: qemu: use VIR_AUTOPTR for aggregate types src/util/viriscsi.c | 99 ++++------ src/util/virmacaddr.c | 6 + src/util/virmacaddr.h | 4 + src/util/virnetdev.c | 412 +++++++++++++++------------------------- src/util/virnetdev.h | 4 + src/util/virnetdevbridge.c | 45 ++--- src/util/virnetdevip.c | 157 ++++++--------- src/util/virnetdevip.h | 4 + src/util/virnetdevmacvlan.c | 41 ++-- src/util/virnetdevopenvswitch.c | 131 +++++-------- src/util/virnetdevtap.c | 11 +- src/util/virnetdevveth.c | 33 ++-- src/util/virnetlink.c | 62 +++--- src/util/virnuma.c | 107 ++++------- src/util/virperf.c | 20 +- src/util/virperf.h | 8 +- src/util/virpidfile.c | 185 ++++++------------ src/util/virprocess.c | 68 +++---- src/util/virqemu.c | 50 ++--- src/util/virsocketaddr.c | 113 +++++------ src/util/virsocketaddr.h | 9 +- 21 files changed, 610 insertions(+), 959 deletions(-) -- 1.8.3.1

4 84