July 2018 - Devel - libvirt List Archives

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

08 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 libvirt v2 0/9] Fix virConnectRegisterCloseCallback and get rid of global variables
by Marc Hartmayer 08 Aug '18

08 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 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 (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

[libvirt] [PATCH] qemu: emit error when trying to update blkiotune group_name in qemuDomainChangeDiskLive
by Katerina Koukiou 06 Aug '18

06 Aug '18

All rest of blkiotune parameters are not updatable through UpdateDeviceFlags API. https://bugzilla.redhat.com/show_bug.cgi?id=1601677 Signed-off-by: Katerina Koukiou <kkoukiou(a)redhat.com> --- The BZ was requesting to add support for updating the group_name for blkdeviotune here, though, all the rest of blkdeviotune elements are not updatable though UpdateDeviceFlags API. I think emmiting error and keeping all blkiodevtune parameters updatable in a consistent way is the right way to go. src/qemu/qemu_domain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index de056272e8..0aa440e0b5 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8791,6 +8791,9 @@ qemuDomainDiskChangeSupported(virDomainDiskDefPtr disk, CHECK_EQ(blkdeviotune.size_iops_sec, "blkdeviotune size_iops_sec", true); + CHECK_EQ(blkdeviotune.group_name, + "blkdeviotune group_name", + true); if (disk->serial && STRNEQ_NULLABLE(disk->serial, orig_disk->serial)) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, -- 2.17.1

2 1

[libvirt] [PATCH v3 0/4] iscsi-direct: first part
by clem＠lse.epita.fr 06 Aug '18

06 Aug '18

From: Clementine Hayat <clem(a)lse.epita.fr> Hello, This is the implementation of the iscsi-direct backend storage pool version 3. v1: https://www.redhat.com/archives/libvir-list/2018-July/msg00918.html v2: https://www.redhat.com/archives/libvir-list/2018-July/msg01528.html Best Regards, -- Clementine Hayat Clementine Hayat (4): configure: Introduce libiscsi in build system storage: Introduce iscsi_direct pool type storage: Implement iscsi_direct pool backend news: add storage pool iscsi-direct configure.ac | 9 +- docs/news.xml | 9 + docs/schemas/storagepool.rng | 35 ++ docs/storage.html.in | 30 ++ m4/virt-libiscsi.m4 | 30 ++ m4/virt-storage-iscsi-direct.m4 | 44 ++ src/conf/domain_conf.c | 1 + src/conf/storage_conf.c | 22 +- src/conf/storage_conf.h | 1 + src/conf/virstorageobj.c | 2 + src/storage/Makefile.inc.am | 24 + src/storage/storage_backend.c | 6 + src/storage/storage_backend_iscsi_direct.c | 452 ++++++++++++++++++ src/storage/storage_backend_iscsi_direct.h | 6 + src/storage/storage_driver.c | 1 + .../pool-iscsi-direct-auth.xml | 14 + .../pool-iscsi-direct.xml | 12 + .../pool-iscsi-direct-auth.xml | 17 + .../pool-iscsi-direct.xml | 14 + tests/storagepoolxml2xmltest.c | 2 + tools/virsh-pool.c | 3 + 21 files changed, 728 insertions(+), 6 deletions(-) create mode 100644 m4/virt-libiscsi.m4 create mode 100644 m4/virt-storage-iscsi-direct.m4 create mode 100644 src/storage/storage_backend_iscsi_direct.c create mode 100644 src/storage/storage_backend_iscsi_direct.h create mode 100644 tests/storagepoolxml2xmlin/pool-iscsi-direct-auth.xml create mode 100644 tests/storagepoolxml2xmlin/pool-iscsi-direct.xml create mode 100644 tests/storagepoolxml2xmlout/pool-iscsi-direct-auth.xml create mode 100644 tests/storagepoolxml2xmlout/pool-iscsi-direct.xml -- 2.18.0

4 8

[libvirt] [RFC] secdrivers remembering original labels
by Michal Privoznik 06 Aug '18

06 Aug '18

Dear list, we have this very old bug [1] that I just keep pushing in front of me. I made several attempts to fix it. However, none of them made into the tree. I guess it's time to have discussion what to do about it. IIRC, the algorithm that I implemented last was to keep original label in XATTRs (among with some ref counter) and the last one to restore the label will look there and find the original label. There was a problem with two libvirtds fighting over a file on shared FS. So I guess my question is can we come up with a design that would work? Or at least work to the extent that we're satisfied with? Personally, I like the XATTRs approach. And to resolve the NFS race we can invent yet another lockspace to guard labelling - I also have a bug for that [2] (although, I'm not that familiar with lockspaces). I guess doing disk metadata locking is not going to be trivial, is it? Michal 1: https://bugzilla.redhat.com/show_bug.cgi?id=547546 2: https://bugzilla.redhat.com/show_bug.cgi?id=1524792

3 7

[libvirt] [PATCH 0/3] conf: standardize naming
by Anya Harter 03 Aug '18

03 Aug '18

on vir*ObjListExport call stack Anya Harter (3): conf: rename structs used by Export function conf: rename Export Callback functions conf: rename Match functions src/conf/virinterfaceobj.c | 10 +++++----- src/conf/virnetworkobj.c | 16 ++++++++-------- src/conf/virnodedeviceobj.c | 4 ++-- src/conf/virsecretobj.c | 10 +++++----- src/conf/virstorageobj.c | 24 ++++++++++++------------ 5 files changed, 32 insertions(+), 32 deletions(-) -- 2.17.1

2 6

[libvirt] Entering freeze for libvirt-4.6.0
by Daniel Veillard 02 Aug '18

02 Aug '18

As suggested yesterday, I have just tagged the release candidate 1 in git, and pushed signed tarbal and rpms to the usual place: ftp://libvirt.org/libvirt/ seems to work fine with my limited testing, and https://ci.centos.org/view/libvirt/ is all green (except for virt-viewer-master-rpm ?) so things looks pretty good for me but please try it out on different systems and OSes. If everything goes well I will push rc2 on Tuesday targetting Thursday for the final release (or Friday if I get stuck in travels). thanks in advance for trying it out ! Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

11 31

[libvirt] [PATCH for-3.1] s390x: remove 's390-squash-mcss' option
by Cornelia Huck 02 Aug '18

02 Aug '18

This option has been deprecated for two releases; remove it. Signed-off-by: Cornelia Huck <cohuck(a)redhat.com> --- hw/s390x/3270-ccw.c | 2 +- hw/s390x/css-bridge.c | 1 - hw/s390x/css.c | 6 ++---- hw/s390x/s390-ccw.c | 2 +- hw/s390x/s390-virtio-ccw.c | 37 ++----------------------------------- hw/s390x/virtio-ccw.c | 2 +- include/hw/s390x/css-bridge.h | 1 - include/hw/s390x/css.h | 9 +++------ include/hw/s390x/s390-virtio-ccw.h | 1 - qemu-deprecated.texi | 8 -------- qemu-options.hx | 10 ---------- target/s390x/cpu.c | 10 ---------- target/s390x/cpu.h | 1 - 13 files changed, 10 insertions(+), 80 deletions(-) diff --git a/hw/s390x/3270-ccw.c b/hw/s390x/3270-ccw.c index 3af13ea027..cf58b81fc0 100644 --- a/hw/s390x/3270-ccw.c +++ b/hw/s390x/3270-ccw.c @@ -104,7 +104,7 @@ static void emulated_ccw_3270_realize(DeviceState *ds, Error **errp) SubchDev *sch; Error *err = NULL; - sch = css_create_sch(cdev->devno, cbus->squash_mcss, errp); + sch = css_create_sch(cdev->devno, errp); if (!sch) { return; } diff --git a/hw/s390x/css-bridge.c b/hw/s390x/css-bridge.c index a02d708239..1bd6c8b458 100644 --- a/hw/s390x/css-bridge.c +++ b/hw/s390x/css-bridge.c @@ -106,7 +106,6 @@ VirtualCssBus *virtual_css_bus_init(void) /* Create bus on bridge device */ bus = qbus_create(TYPE_VIRTUAL_CSS_BUS, dev, "virtual-css"); cbus = VIRTUAL_CSS_BUS(bus); - cbus->squash_mcss = s390_get_squash_mcss(); /* Enable hotplugging */ qbus_set_hotplug_handler(bus, dev, &error_abort); diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 5424ea4562..5a9fe45ce8 100644 --- a/hw/s390x/css.c +++ b/hw/s390x/css.c @@ -2359,15 +2359,13 @@ const PropertyInfo css_devid_ro_propinfo = { .get = get_css_devid, }; -SubchDev *css_create_sch(CssDevId bus_id, bool squash_mcss, Error **errp) +SubchDev *css_create_sch(CssDevId bus_id, Error **errp) { uint16_t schid = 0; SubchDev *sch; if (bus_id.valid) { - if (squash_mcss) { - bus_id.cssid = channel_subsys.default_cssid; - } else if (!channel_subsys.css[bus_id.cssid]) { + if (!channel_subsys.css[bus_id.cssid]) { css_create_css_image(bus_id.cssid, false); } diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c index 214c940593..d1280bf631 100644 --- a/hw/s390x/s390-ccw.c +++ b/hw/s390x/s390-ccw.c @@ -78,7 +78,7 @@ static void s390_ccw_realize(S390CCWDevice *cdev, char *sysfsdev, Error **errp) goto out_err_propagate; } - sch = css_create_sch(ccw_dev->devno, cbus->squash_mcss, &err); + sch = css_create_sch(ccw_dev->devno, &err); if (!sch) { goto out_mdevid_free; } diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 7983185d04..380a41d806 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -282,19 +282,8 @@ static void ccw_init(MachineState *machine) virtio_ccw_register_hcalls(); s390_enable_css_support(s390_cpu_addr2state(0)); - /* - * Non mcss-e enabled guests only see the devices from the default - * css, which is determined by the value of the squash_mcss property. - */ - if (css_bus->squash_mcss) { - ret = css_create_css_image(0, true); - } else { - ret = css_create_css_image(VIRTUAL_CSSID, true); - } - if (qemu_opt_get(qemu_get_machine_opts(), "s390-squash-mcss")) { - warn_report("The machine property 's390-squash-mcss' is deprecated" - " (obsoleted by lifting the cssid restrictions)."); - } + + ret = css_create_css_image(VIRTUAL_CSSID, true); assert(ret == 0); if (css_migration_enabled()) { @@ -575,21 +564,6 @@ static void machine_set_loadparm(Object *obj, const char *val, Error **errp) ms->loadparm[i] = ' '; /* pad right with spaces */ } } -static inline bool machine_get_squash_mcss(Object *obj, Error **errp) -{ - S390CcwMachineState *ms = S390_CCW_MACHINE(obj); - - return ms->s390_squash_mcss; -} - -static inline void machine_set_squash_mcss(Object *obj, bool value, - Error **errp) -{ - S390CcwMachineState *ms = S390_CCW_MACHINE(obj); - - ms->s390_squash_mcss = value; -} - static inline void s390_machine_initfn(Object *obj) { object_property_add_bool(obj, "aes-key-wrap", @@ -614,13 +588,6 @@ static inline void s390_machine_initfn(Object *obj) " to upper case) to pass to machine loader, boot manager," " and guest kernel", NULL); - object_property_add_bool(obj, "s390-squash-mcss", - machine_get_squash_mcss, - machine_set_squash_mcss, NULL); - object_property_set_description(obj, "s390-squash-mcss", "(deprecated) " - "enable/disable squashing subchannels into the default css", - NULL); - object_property_set_bool(obj, false, "s390-squash-mcss", NULL); } static const TypeInfo ccw_machine_info = { diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c index 7ddb378d52..3156e8d6e1 100644 --- a/hw/s390x/virtio-ccw.c +++ b/hw/s390x/virtio-ccw.c @@ -700,7 +700,7 @@ static void virtio_ccw_device_realize(VirtioCcwDevice *dev, Error **errp) SubchDev *sch; Error *err = NULL; - sch = css_create_sch(ccw_dev->devno, cbus->squash_mcss, errp); + sch = css_create_sch(ccw_dev->devno, errp); if (!sch) { return; } diff --git a/include/hw/s390x/css-bridge.h b/include/hw/s390x/css-bridge.h index cf0860432a..5a0203be5f 100644 --- a/include/hw/s390x/css-bridge.h +++ b/include/hw/s390x/css-bridge.h @@ -28,7 +28,6 @@ typedef struct VirtualCssBridge { /* virtual css bus type */ typedef struct VirtualCssBus { BusState parent_obj; - bool squash_mcss; } VirtualCssBus; #define TYPE_VIRTUAL_CSS_BUS "virtual-css-bus" diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h index 35facb47d2..9da5912921 100644 --- a/include/hw/s390x/css.h +++ b/include/hw/s390x/css.h @@ -266,11 +266,8 @@ extern const PropertyInfo css_devid_ro_propinfo; /** * Create a subchannel for the given bus id. * - * If @p bus_id is valid, and @p squash_mcss is true, verify that it is - * not already in use in the default css, and find a free devno from the - * default css image for it. - * If @p bus_id is valid, and @p squash_mcss is false, verify that it is - * not already in use, and find a free devno for it. + * If @p bus_id is valid, verify that it is not already in use, and find a + * free devno for it. * If @p bus_id is not valid find a free subchannel id and device number * across all subchannel sets and all css images starting from the default * css image. @@ -282,7 +279,7 @@ extern const PropertyInfo css_devid_ro_propinfo; * The caller becomes owner of the returned subchannel structure and * is responsible for unregistering and freeing it. */ -SubchDev *css_create_sch(CssDevId bus_id, bool squash_mcss, Error **errp); +SubchDev *css_create_sch(CssDevId bus_id, Error **errp); /** Turn on css migration */ void css_register_vmstate(void); diff --git a/include/hw/s390x/s390-virtio-ccw.h b/include/hw/s390x/s390-virtio-ccw.h index ab88d49d10..e9c4f4182b 100644 --- a/include/hw/s390x/s390-virtio-ccw.h +++ b/include/hw/s390x/s390-virtio-ccw.h @@ -29,7 +29,6 @@ typedef struct S390CcwMachineState { bool aes_key_wrap; bool dea_key_wrap; uint8_t loadparm[8]; - bool s390_squash_mcss; } S390CcwMachineState; typedef struct S390CcwMachineClass { diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 9920a85adc..09f7b22fb1 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -126,14 +126,6 @@ The ``-nodefconfig`` argument is a synonym for ``-no-user-config``. The @option{--balloon virtio} argument has been superseded by @option{--device virtio-balloon}. -@subsection -machine s390-squash-mcss=on|off (since 2.12.0) - -The ``s390-squash-mcss=on`` property has been obsoleted by allowing the -cssid to be chosen freely. Instead of squashing subchannels into the -default channel subsystem image for guests that do not support multiple -channel subsystems, all devices can be put into the default channel -subsystem image. - @subsection -fsdev handle (since 2.12.0) The ``handle'' fsdev backend does not support symlinks and causes the 9p diff --git a/qemu-options.hx b/qemu-options.hx index b1bf0f485f..e57cec96a5 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -43,7 +43,6 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \ " suppress-vmdesc=on|off disables self-describing migration (default=off)\n" " nvdimm=on|off controls NVDIMM support (default=off)\n" " enforce-config-section=on|off enforce configuration section migration (default=off)\n" - " s390-squash-mcss=on|off (deprecated) controls support for squashing into default css (default=off)\n" " memory-encryption=@var{} memory encryption object to use (default=none)\n", QEMU_ARCH_ALL) STEXI @@ -96,15 +95,6 @@ controls whether DEA wrapping keys will be created to allow execution of DEA cryptographic functions. The default is on. @item nvdimm=on|off Enables or disables NVDIMM support. The default is off. -@item s390-squash-mcss=on|off -Enables or disables squashing subchannels into the default css. -The default is off. -NOTE: This property is deprecated and will be removed in future releases. -The ``s390-squash-mcss=on`` property has been obsoleted by allowing the -cssid to be chosen freely. Instead of squashing subchannels into the -default channel subsystem image for guests that do not support multiple -channel subsystems, all devices can be put into the default channel -subsystem image. @item enforce-config-section=on|off If @option{enforce-config-section} is set to @var{on}, force migration code to send configuration section even if the machine-type sets the diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c index 271c5ce652..8ed4823d6e 100644 --- a/target/s390x/cpu.c +++ b/target/s390x/cpu.c @@ -421,16 +421,6 @@ void s390_crypto_reset(void) } } -bool s390_get_squash_mcss(void) -{ - if (object_property_get_bool(OBJECT(qdev_get_machine()), "s390-squash-mcss", - NULL)) { - return true; - } - - return false; -} - void s390_enable_css_support(S390CPU *cpu) { if (kvm_enabled()) { diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h index 2c3dd2d189..86b66dfeac 100644 --- a/target/s390x/cpu.h +++ b/target/s390x/cpu.h @@ -713,7 +713,6 @@ static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data arg) /* cpu.c */ void s390_crypto_reset(void); -bool s390_get_squash_mcss(void); int s390_set_memory_limit(uint64_t new_limit, uint64_t *hw_limit); void s390_cmma_reset(void); void s390_enable_css_support(S390CPU *cpu); -- 2.14.4

6 14

[libvirt] [jenkins-ci PATCH 0/8] lcitool: Cleanups and improvements
by Andrea Bolognani 01 Aug '18

01 Aug '18

This series makes the guests/ directory less crowded by moving a bunch of files to subdirectories, enhances the lcitool script so that it works when called from any directory, and introduces the ability to skip installation of build dependencies for projects you don't care about. Some of these changes pave the way for introducing [secret feature redacted] later on. Andrea Bolognani (8): lcitool: Make the script location-independent lcitool: Use JSON to pass extra-vars lcitool: Pass base and playbook_base to Ansible guests: Move update playbook and related resources guests: Drop install_config from inventory guests: Move install configs lcitool: Allow installing a subset of build dependencies guests: Update documentation guests/README.markdown | 38 ++++++-- guests/{ => configs}/kickstart.cfg | 0 guests/{ => configs}/preseed.cfg | 0 guests/host_vars/libvirt-centos-7/install.yml | 1 - guests/host_vars/libvirt-debian-8/install.yml | 1 - guests/host_vars/libvirt-debian-9/install.yml | 1 - .../host_vars/libvirt-debian-sid/install.yml | 1 - .../host_vars/libvirt-fedora-27/install.yml | 1 - .../host_vars/libvirt-fedora-28/install.yml | 1 - .../libvirt-fedora-rawhide/install.yml | 1 - .../host_vars/libvirt-ubuntu-16/install.yml | 1 - .../host_vars/libvirt-ubuntu-18/install.yml | 1 - guests/lcitool | 96 ++++++++++++++----- .../{site.yml => playbooks/update/main.yml} | 30 +++--- guests/{ => playbooks/update}/tasks/base.yml | 6 +- .../update}/tasks/bootloader.yml | 0 .../update}/tasks/bootstrap.yml | 0 .../{ => playbooks/update}/tasks/jenkins.yml | 4 +- .../{ => playbooks/update}/tasks/kludges.yml | 0 .../{ => playbooks/update}/tasks/packages.yml | 2 +- guests/{ => playbooks/update}/tasks/paths.yml | 0 .../{ => playbooks/update}/tasks/services.yml | 0 guests/{ => playbooks/update}/tasks/users.yml | 4 +- .../update}/templates/bash_profile.j2 | 0 .../update}/templates/bashrc.j2 | 0 .../update}/templates/ccache.conf.j2 | 0 .../fedora-rawhide-kernel-nodebug.repo.j2 | 0 .../update}/templates/jenkins.service.j2 | 0 .../templates/jessie-backports.preferences.j2 | 0 .../templates/jessie-backports.sources.j2 | 0 30 files changed, 128 insertions(+), 61 deletions(-) rename guests/{ => configs}/kickstart.cfg (100%) rename guests/{ => configs}/preseed.cfg (100%) rename guests/{site.yml => playbooks/update/main.yml} (52%) rename guests/{ => playbooks/update}/tasks/base.yml (92%) rename guests/{ => playbooks/update}/tasks/bootloader.yml (100%) rename guests/{ => playbooks/update}/tasks/bootstrap.yml (100%) rename guests/{ => playbooks/update}/tasks/jenkins.yml (92%) rename guests/{ => playbooks/update}/tasks/kludges.yml (100%) rename guests/{ => playbooks/update}/tasks/packages.yml (96%) rename guests/{ => playbooks/update}/tasks/paths.yml (100%) rename guests/{ => playbooks/update}/tasks/services.yml (100%) rename guests/{ => playbooks/update}/tasks/users.yml (95%) rename guests/{ => playbooks/update}/templates/bash_profile.j2 (100%) rename guests/{ => playbooks/update}/templates/bashrc.j2 (100%) rename guests/{ => playbooks/update}/templates/ccache.conf.j2 (100%) rename guests/{ => playbooks/update}/templates/fedora-rawhide-kernel-nodebug.repo.j2 (100%) rename guests/{ => playbooks/update}/templates/jenkins.service.j2 (100%) rename guests/{ => playbooks/update}/templates/jessie-backports.preferences.j2 (100%) rename guests/{ => playbooks/update}/templates/jessie-backports.sources.j2 (100%) -- 2.17.1

2 17