- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: Clean up qemuDomainSecretPrepare
by John Ferlan 13 Sep '17

13 Sep '17

No need to pass a @driver parameter since all that's done is deref the @cfg especially since the only caller can just pass an already referenced @cfg. Also, looks like commit id '0298531b' at one time had a different name for the API, so I took the liberty of fixing the comments too since I would already be updating them for the @cfg variable. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Saw this while doing some updates for the recently posted VxHS series. src/qemu/qemu_domain.c | 11 ++++------- src/qemu/qemu_domain.h | 2 +- src/qemu/qemu_process.c | 2 +- 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index cbee151..4cd0087 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -7454,7 +7454,7 @@ qemuDomainPrepareChannel(virDomainChrDefPtr channel, } -/* qemuProcessPrepareDomainChardevSourceTLS: +/* qemuDomainPrepareChardevSourceTLS: * @source: pointer to host interface data for char devices * @cfg: driver configuration * @@ -7478,19 +7478,18 @@ qemuDomainPrepareChardevSourceTLS(virDomainChrSourceDefPtr source, } -/* qemuProcessPrepareDomainChardevSource: +/* qemuDomainPrepareChardevSource: * @def: live domain definition - * @driver: qemu driver + * @cfg: driver configuration * * Iterate through all devices that use virDomainChrSourceDefPtr as host * interface part. */ void qemuDomainPrepareChardevSource(virDomainDefPtr def, - virQEMUDriverPtr driver) + virQEMUDriverConfigPtr cfg) { size_t i; - virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); for (i = 0; i < def->nserials; i++) qemuDomainPrepareChardevSourceTLS(def->serials[i]->source, cfg); @@ -7515,8 +7514,6 @@ qemuDomainPrepareChardevSource(virDomainDefPtr def, for (i = 0; i < def->nredirdevs; i++) qemuDomainPrepareChardevSourceTLS(def->redirdevs[i]->source, cfg); - - virObjectUnref(cfg); } diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index f93b09b..4b030ae 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -842,7 +842,7 @@ void qemuDomainPrepareChardevSourceTLS(virDomainChrSourceDefPtr source, ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); void qemuDomainPrepareChardevSource(virDomainDefPtr def, - virQEMUDriverPtr driver) + virQEMUDriverConfigPtr cfg) ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2); int qemuDomainPrepareShmemChardev(virDomainShmemDefPtr shmem) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 364c359..44df858 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5327,7 +5327,7 @@ qemuProcessPrepareDomain(virConnectPtr conn, goto cleanup; VIR_DEBUG("Prepare chardev source backends for TLS"); - qemuDomainPrepareChardevSource(vm->def, driver); + qemuDomainPrepareChardevSource(vm->def, cfg); VIR_DEBUG("Add secrets to disks, hostdevs, and chardevs"); if (qemuDomainSecretPrepare(conn, driver, vm) < 0) -- 2.9.5

2 2

[libvirt] external snapshots bug
by Khasan Khafizov 13 Sep '17

13 Sep '17

Suppose we have a disk with several external snapshots of it. This disk is attached to some domain. I found that after destroying and starting the domain the xml of attached disk doesn't contain all backingStore that it has to. Before the restart the part of domain xml that relates to attached disk looks like this: <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source file='...'/> > <backingStore type='file' index='1'> > <format type='qcow2'/>  > <source file='...'/> > <backingStore type='file' index='2'> > <format type='qcow2'/> > <source file='...'/> > <backingStore type='file' index='3'> > <format type='qcow2'/> > <source file='...'/> > <backingStore/> > </backingStore> > </backingStore> > </backingStore> > </disk> And after the restart like this: <disk type='file' device='disk'> > <driver name='qemu' type='qcow2'/> > <source file='...'/> > <backingStore type='file' index='1'> > <format type='raw'/>  > <source file='...'/> > <backingStore/> > </backingStore> > </disk> So, the difference in two xml not only in depth of backing stores but in format type also. The result of it is that you can't run blockcommit that will commit overlay into base image if they don't have direct relations (if for example overlay is child of child of base image). Virsh says it can't find base in chain ( exception <https://github.com/libvirt/libvirt/blob/cdecfbed027ab242467580a897a636be82d…> ). Then I got that libvirt stops calling virStorageFileGetMetadataRecurse <https://github.com/libvirt/libvirt/blob/ed8661a309c96e4a1573dc0ca2c76ea7ff1…> function after first call because it thinks that format of first backingStore of disk is raw instead of qcow2. I solved it by adding to the qemu config the following line: > allow_disk_format_probing = 1 But in qemu config it was marked as secure hole. Idea of fix is that we can try assume that backing store of qcow is qcow insted of raw, but I really don't know what to do to implement this idea if it at all possible Thanks!

2 1

[libvirt] [PATCH] domain: add limit description of parameter 'size' for blockPeek and memoryPeek
by Chen Hanxiao 13 Sep '17

13 Sep '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> We had 'size' limits for virDomainMemoryPeek and virDomainBlockPeek by macro REMOTE_DOMAIN_BLOCK_PEEK_BUFFER_MAX and REMOTE_DOMAIN_MEMORY_PEEK_BUFFER_MAX. The descriptions of the two functions only emphasized RPC buffer size. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/libvirt-domain.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index ca5a153..646ce72 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -5802,6 +5802,9 @@ virDomainMemoryStats(virDomainPtr dom, virDomainMemoryStatPtr stats, * within the device or file. 'size' may be 0 to test if the * call would succeed. * + * 'size' should be <= 1048576(1M). Since v1.0.5, 'size' had been + * raised up to 4194304(4M). + * * 'buffer' is the return buffer and must be at least 'size' bytes. * * NB. The remote driver imposes a 64K byte limit on 'size'. @@ -5941,6 +5944,9 @@ virDomainBlockResize(virDomainPtr dom, * 'buffer' is the return buffer and must be at least 'size' bytes. * 'size' may be 0 to test if the call would succeed. * + * 'size' should be <= 1048576(1M). Since v1.0.5, 'size' had been + * raised up to 4194304(4M). + * * NB. The remote driver imposes a 64K byte limit on 'size'. * For your program to be able to work reliably over a remote * connection you should split large requests to <= 65536 bytes. -- 2.7.5

1 1

[libvirt] [PATCH] qemu: blockcopy: Probe image format only with VIR_DOMAIN_BLOCK_COPY_REUSE_EXT
by Peter Krempa 12 Sep '17

12 Sep '17

Commit 703abf1d7 changed the logic so that we don't attempt to re-create the image if it's a block device. This was done by modifying the 'reuse' variable. Unfortunately after modifying it one of the uses was to infer whether we should probe the disk format. After changes in the commit mentioned above we would attempt the probe if the target of the copy is a block device and the format was not provided explicitly rather than using the format of the disk. Fix it by explicitly checking whether the user requested a reuse of the disk rather than the modified boolean flag. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490826 --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 70cdc88e1..23a51359d 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16988,7 +16988,7 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm, goto endjob; if (!mirror->format) { - if (!reuse) { + if (!(flags & VIR_DOMAIN_BLOCK_COPY_REUSE_EXT)) { mirror->format = disk->src->format; } else { /* If the user passed the REUSE_EXT flag, then either they -- 2.14.1

2 1

[libvirt] libvirt stats units
by Marko Myllynen 12 Sep '17

12 Sep '17

Hi, virsh.pod states: "balloon.maximum" - the maximum memory in kiB allowed "balloon.swap_in" - the amount of data read from swap space (in kB) But to me it seems there's not such kb vs kib difference [1] so it would be nice to have a confirmation which one is actually used? 1) http://elixir.free-electrons.com/linux/v4.13/source/drivers/virtio/virtio_b… Thanks, -- Marko Myllynen

2 1

[libvirt] [PATCH v2] storage: Adjust expected format for Disk startup processing
by John Ferlan 12 Sep '17

12 Sep '17

https://bugzilla.redhat.com/show_bug.cgi?id=1464313 If a Disk pool was defined/created using XML that either didn't specify a specific format or specified format type='unknown', then restarting a pool after an initial disk backend build with overwrite would fail after a libvirtd restart for a non-autostarted pool. This is because the persistent pool data is not updated during pool build w/ overwrite processing to have the VIR_STORAGE_POOL_DISK_DOS default format. So in addition to the alteration done during disk build processing, alter the default expectation for disk startup to be DOS if nothing has been defined yet. That will either succeed if the pool had been successfully built previously using the default DOS format or fail with a message indicating the format is something else that does not match the expect format 'dos'. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: https://www.redhat.com/archives/libvir-list/2017-September/msg00124.html Changes since v1... * Use a totally different methodology. Rather than updating the persistent config file, alter the start processing to handle the unknown setting in the persistent file properly. src/storage/storage_backend_disk.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index e8f67bb00..bce3b4e2a 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -446,8 +446,7 @@ static int virStorageBackendDiskStartPool(virConnectPtr conn ATTRIBUTE_UNUSED, virStoragePoolObjPtr pool) { - const char *format = - virStoragePoolFormatDiskTypeToString(pool->def->source.format); + const char *format; const char *path = pool->def->source.devices[0].path; virWaitForDevices(); @@ -458,6 +457,9 @@ virStorageBackendDiskStartPool(virConnectPtr conn ATTRIBUTE_UNUSED, return -1; } + if (pool->def->source.format == VIR_STORAGE_POOL_DISK_UNKNOWN) + pool->def->source.format = VIR_STORAGE_POOL_DISK_DOS; + format = virStoragePoolFormatDiskTypeToString(pool->def->source.format); if (!virStorageBackendDeviceIsEmpty(path, format, false)) return -1; -- 2.13.5

2 1

[libvirt] [PATCH v2] qemu: Provide default LUN=0 for iSCSI if not provided
by John Ferlan 12 Sep '17

12 Sep '17

https://bugzilla.redhat.com/show_bug.cgi?id=1477880 If the "/#" is missing from the provided iSCSI path, then we need to provide the default LUN of /0; otherwise, QEMU will fail to parse the URL causing a failure to either create the guest or hotplug attach the storage. During post parse, for any iSCSI disk or hostdev, scan the source path looking for the presence of '/', if found, then we can assume the LUN is provided. If not found, alter the input XML to add the "/0". This will cause the generated XML to have the generated value when the domain config is saved after post parse. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: https://www.redhat.com/archives/libvir-list/2017-September/msg00122.html Alter the patch to make the adjustment during device post parsing rather than command line creation as requested by code review. This will alter the output XML as well as the command line arguments for those entries that don't supply a LUN. We had a few, so that works out testing wise! src/conf/domain_conf.c | 43 ++++++++++++++++++++++ .../qemuargv2xml-disk-drive-network-iscsi.xml | 2 +- .../qemuxml2argv-disk-drive-network-iscsi-lun.args | 2 +- .../qemuxml2argv-disk-drive-network-iscsi.args | 2 +- .../qemuxml2argv-hostdev-scsi-lsi-iscsi.args | 2 +- .../qemuxml2argv-hostdev-scsi-virtio-iscsi.args | 2 +- .../qemuxml2xmlout-disk-drive-network-iscsi.xml | 2 +- .../qemuxml2xmlout-hostdev-scsi-lsi-iscsi.xml | 2 +- .../qemuxml2xmlout-hostdev-scsi-virtio-iscsi.xml | 2 +- 9 files changed, 51 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 676fc0f34..a43b25c31 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -4308,16 +4308,54 @@ virDomainHostdevAssignAddress(virDomainXMLOptionPtr xmlopt, } +/** + * virDomainPostParseCheckISCSIPath + * @srcpath: Source path read (a/k/a, IQN) either disk or hostdev + * + * The details of an IQN is defined by RFC 3720 and 3721, but + * we just need to make sure there's a lun provided. If not + * provided, then default to zero. For an ISCSI LUN that is + * is provided by /dev/disk/by-path/... , then that path will + * have the specific lun requested. + * + * Returns 0 on success, -1 on failure + */ +static int +virDomainPostParseCheckISCSIPath(char **srcpath) +{ + char *path = NULL; + + if (strchr(*srcpath, '/')) + return 0; + + if (virAsprintf(&path, "%s/0", *srcpath) < 0) + return -1; + VIR_FREE(*srcpath); + VIR_STEAL_PTR(*srcpath, path); + return 0; +} + + static int virDomainHostdevDefPostParse(virDomainHostdevDefPtr dev, const virDomainDef *def, virDomainXMLOptionPtr xmlopt) { + virDomainHostdevSubsysSCSIPtr scsisrc; + if (dev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) return 0; switch (dev->source.subsys.type) { case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI: + scsisrc = &dev->source.subsys.u.scsi; + if (scsisrc->protocol == VIR_DOMAIN_HOSTDEV_SCSI_PROTOCOL_TYPE_ISCSI) { + virDomainHostdevSubsysSCSIiSCSIPtr iscsisrc = &scsisrc->u.iscsi; + + if (virDomainPostParseCheckISCSIPath(&iscsisrc->path) < 0) + return -1; + } + if (dev->info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && virDomainHostdevAssignAddress(xmlopt, def, dev) < 0) { virReportError(VIR_ERR_XML_ERROR, "%s", @@ -4455,6 +4493,11 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev, } } + if (disk->src->type == VIR_STORAGE_TYPE_NETWORK && + disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI && + virDomainPostParseCheckISCSIPath(&disk->src->path) < 0) + return -1; + if (disk->bus != VIR_DOMAIN_DISK_BUS_VIRTIO && virDomainCheckVirtioOptions(disk->virtio) < 0) return -1; diff --git a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml index 23542fa1d..694412b5c 100644 --- a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml +++ b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml @@ -16,7 +16,7 @@ <emulator>/usr/bin/qemu-system-i686</emulator> <disk type='network' device='disk'> <driver name='qemu' type='raw'/> - <source protocol='iscsi' name='iqn.1992-01.com.example'> + <source protocol='iscsi' name='iqn.1992-01.com.example/0'> <host name='example.org' port='6000'/> </source> <target dev='vda' bus='virtio'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args index b25f3a0d6..0fbfd9a6d 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args @@ -21,7 +21,7 @@ server,nowait \ -boot c \ -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 \ -usb \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,format=raw,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,format=raw,\ if=none,id=drive-scsi0-0-0-0 \ -device scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args index a1d93af10..ed15fda21 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args @@ -19,7 +19,7 @@ server,nowait \ -no-acpi \ -boot c \ -usb \ --drive file=iscsi://example.org:6000/iqn.1992-01.com.example,format=raw,\ +-drive file=iscsi://example.org:6000/iqn.1992-01.com.example/0,format=raw,\ if=none,id=drive-virtio-disk0 \ -device virtio-blk-pci,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,\ id=virtio-disk0 \ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args index 43c555a50..07ae9f592 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args @@ -22,7 +22,7 @@ server,nowait \ -usb \ -drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-ide0-0-0 \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,if=none,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,if=none,\ format=raw,id=drive-hostdev0 \ -device scsi-generic,bus=scsi0.0,scsi-id=4,drive=drive-hostdev0,id=hostdev0 \ -drive file=iscsi://example.org:3260/iqn.1992-01.com.example/1,if=none,\ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args index a78e3092c..d80c85918 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args @@ -22,7 +22,7 @@ server,nowait \ -usb \ -drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-ide0-0-0 \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,if=none,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,if=none,\ format=raw,id=drive-hostdev0 \ -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=2,lun=4,\ drive=drive-hostdev0,id=hostdev0 \ diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-iscsi.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-iscsi.xml index 23542fa1d..694412b5c 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-iscsi.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-iscsi.xml @@ -16,7 +16,7 @@ <emulator>/usr/bin/qemu-system-i686</emulator> <disk type='network' device='disk'> <driver name='qemu' type='raw'/> - <source protocol='iscsi' name='iqn.1992-01.com.example'> + <source protocol='iscsi' name='iqn.1992-01.com.example/0'> <host name='example.org' port='6000'/> </source> <target dev='vda' bus='virtio'/> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-lsi-iscsi.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-lsi-iscsi.xml index e19bce6ea..b7312ca4f 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-lsi-iscsi.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-lsi-iscsi.xml @@ -32,7 +32,7 @@ <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='scsi' managed='yes'> - <source protocol='iscsi' name='iqn.1992-01.com.example'> + <source protocol='iscsi' name='iqn.1992-01.com.example/0'> <host name='example.org' port='3260'/> </source> <address type='drive' controller='0' bus='0' target='0' unit='4'/> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-virtio-iscsi.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-virtio-iscsi.xml index 37635b4f9..ddf780160 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-virtio-iscsi.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-scsi-virtio-iscsi.xml @@ -32,7 +32,7 @@ <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='scsi' managed='yes'> - <source protocol='iscsi' name='iqn.1992-01.com.example'> + <source protocol='iscsi' name='iqn.1992-01.com.example/0'> <host name='example.org' port='3260'/> </source> <address type='drive' controller='0' bus='0' target='2' unit='4'/> -- 2.13.5

2 1

[libvirt] Yet another RFC for CAT
by Martin Kletzander 12 Sep '17

12 Sep '17

Hello everyone. Last couple of weeks [1] I was working on CAT for libvirt. Only clean-ups and minor things were pushed into upstream, but as I'm getting closer and closer to actual functionality I'm seeing a problem with our current (already discussed and approved) design. And I would like to know your thoughts about this, even if you are not familiar with CAT, feel free to keep the questions coming. * Little bit of background about CAT [I wanted to say "Long story short...", but after reading the mail in its entirety before sending it I see it would end up like in "I Should Have Never Gone Ziplining", so I'll rather let you brace for quite elongated or, dare I say, endless stream of words] Since the interface for CAT in the Linux kernel is quite hairy (together with cache information reporting, don't even get me started on that) and might feel pretty inconsistent if you are used to any Linux kernel interface, I would like to summarize how is it used [2]. Feel free to skip this part if you are familiar with it. You can tune how much cache which processes can utilize. Let's talk only about L3 for now, also let's assume only unified caches (no code/data prioritization). For simplicity. The cache is split into parts and when describing the allocation we use hexadecimal representation of bit masks where each bit is the smallest addressable (or rather allocable) part of the cache. Let's say you have 16MB L3 cache which the CPU is able to allocate by chunks of 1MB, so the allocation is represented by 32 bits => 8 hexadecimal characters. Yes, there can be minimum of continuous bits that need to be specified, you can have multiple L3 caches, etc., but that's yet another thing that's not important to what I need to discuss. The whole cache is then referred to as "ffff" in this particular case. Again, for simplicity sake, let's assume the above hardware is constant in future examples. Now, when you want to work with the allocations, it behaves similarly (not the same way, though) as cgroups. The default group, which contains all processes, is in /sys/fs/resctrl, and you can create additional groups (directories under /sys/fs/resctrl). These are flat, not hierarchical, meaning they cannot have subdirectories. Each resource group represents a group of processes (PIDs are written in "tasks" file) that share the same resource settings. One of the settings is the allocation of caches. By default there are no additional resource groups (subdirectories of /sys/fs/resctrl) and the default one occupies all the cache. (IIRC, all bit masks must have only consecutive bits, but I cannot find this in the documentation; let's assume this as well, but feel free to correct me) * Example time (we're almost there) Let's say you have the default group with this setting: L3:0=00ff That is setting of allocation for L3 cache, both code and data, cache id 0 and the occupancy rate is 50% (lower 8MB of the only L3 cache in our example to be precise). If you now create additional resource group, let's say "libvirt-qemu-3-alpine-vcpu3" (truly random name, right?) and set the following allocation: L3:0=0ff0 That specifies it will be allowed to use also 8MB of the cache, but this time from the middle. Half of that will be shared between this group and the default one, the rest is exclusive to this group only. * The current design (finally something libvirt-related, right?) The discussion ended with a conclusion of the following (with my best knowledge, there were so many discussions about so many things that I would spend too much time looking up all of them): - Users should not need to specify bit masks, such complexity should be abstracted. We'll use sizes (e.g. 4MB) - Multiple vCPUs might need to share the same allocation. - Exclusivity of allocations is to be assumed, that is only unoccupied cache should be used for new allocations. The last point seems trivial but it's actually very specific condition that, if removed, can cause several problems. If it's hard to grasp the last point together with the second one, you're on the right track. If not, then I'll try to make a point for why the last point should be removed in 3... 2... 1... * Design flaws 1) Users cannot specify any allocation that would share only part with some other allocation of the domain or the default group. 2) It was not specified what to do with the default resource group. There might be several ways to approach this, with varying pros and cons: a) Treat it as any other group. That is any bit set for this group will be excluded from usable bits when creating new allocation for a domain. - Very predictable behaviour - You will not be able to allocate any amount of cache without previous setting for the default group as that will have all the bits set which will make all the cache unusable b) Automatically remove the appropriate amount of bits that are needed for new domains. - No need to do any change to the system settings in order to use this new feature - We would have to change system settings, which is generally frowned upon when done "automatically" as a side effect of starting a domain, especially for such scarce resource as cache - The change to system settings would not be entirely predictable c) Act like it doesn't exist and don't remove its allocations from consideration - Doesn't really make sense as system processes might be trashing the cache as any VM, moreover when all VM processes without allocations will be based in the default group as well 3) There is no way for users to know what the particular settings are for any running domain. The first point was deemed a corner case. Fair enough on its own, but considering point 2 and its solutions, it is rather difficult for me to justify it. Also, let's say you have domain with 4 vCPUs out of which you know 1 might be trashing the cache, but you don't want to restrict it completely, but others will utilize it very nicely. Sensible allocations for such domain's vCPUs might be: vCPU 0: 000f vCPUs 1-3: ffff as you want vCPUs 1-3 to utilize even the part of cache that might get trashed by vCPU 0. Or they might share some data (especially guest-memory-related). The case above is not possible to set up with only per-vcpu(s) scalar setting. And there are more as you might imagine now. For example how do we behave with iothreads and emulator threads? * My suggestion: - Provide an API for querying and changing the allocation of the default resource group. This would be similar to setting and querying hugepage allocations (see virsh's freepages/allocpages commands). - Let users specify the starting position in addition to the size, i.e. not only specifying "size", but also "from". If "from" is not specified, the whole allocation must be exclusive. If "from" is specified it will be set without checking for collisions. The latter needs them to query the system or know what settings are applied (this should be the case all the time), but is better then adding non-specific and/or meaningless exclusivity settings (how do you specify part-exclusivity of the cache as in the example above) - After starting a domain, fill in any missing information about the allocation (I'm generalizing here, but fro now it would only be the optional "from" attribute) - Add settings not only for vCPUs, but also for other threads as we do with pinning, schedulers, etc. Let me know what you think. As I said before, even if you're not familiar with CAT. And thank you for reading the whole thing or at least skipping to the end. I spend quite some time on this, I changed the underlying code design several times (thanks again for the "consistency" of the design of resctrlfs) and I'm afraid my head is going to burst any moment now. Have a nice day Martin P.S.: I still continue on the implementation, you can follow it on my github [3]. Don't expect the tests to pass or all functions to be complete, thought. You have been warned. [1] Technically months, I can't wrap my head around how much technical debt there is in libvirt. [2] Detailed information in Documentation/x86/intel_rdt_ui.txt [3] https://github.com/nertpinx/libvirt/tree/catwip

3 5

[libvirt] [PATCH] qemu: handle reconnect on chardev hotplug
by ZhiPeng Lu 12 Sep '17

12 Sep '17

The patch passes the reconnect timeout to QEMU by monitor on chardev hotplug. Signed-off-by: ZhiPeng Lu <lu.zhipeng(a)zte.com.cn> --- src/qemu/qemu_monitor_json.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index df5fb7c..4169cd5 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -6444,6 +6444,17 @@ int qemuMonitorJSONGetTPMTypes(qemuMonitorPtr mon, return qemuMonitorJSONGetStringArray(mon, "query-tpm-types", tpmtypes); } +static int +qemuMonitorJSONBuildChrChardevReconnect(virJSONValuePtr object, + const virDomainChrSourceReconnectDef *def) +{ + int ret = 0; + if (def->enabled == VIR_TRISTATE_BOOL_YES) { + ret = virJSONValueObjectAppendNumberUint(object, "reconnect", def->timeout); + } + return ret; +} + static virJSONValuePtr qemuMonitorJSONAttachCharDevCommand(const char *chrID, const virDomainChrSourceDef *chr) @@ -6508,6 +6519,10 @@ qemuMonitorJSONAttachCharDevCommand(const char *chrID, if (virJSONValueObjectAppendString(data, "tls-creds", tlsalias) < 0) goto cleanup; } + + if (qemuMonitorJSONBuildChrChardevReconnect(data, &chr->data.tcp.reconnect) < 0) { + goto cleanup; + } break; case VIR_DOMAIN_CHR_TYPE_UDP: @@ -6545,6 +6560,10 @@ qemuMonitorJSONAttachCharDevCommand(const char *chrID, if (virJSONValueObjectAppendBoolean(data, "wait", false) < 0 || virJSONValueObjectAppendBoolean(data, "server", chr->data.nix.listen) < 0) goto cleanup; + + if (qemuMonitorJSONBuildChrChardevReconnect(data, &chr->data.nix.reconnect) < 0) { + goto cleanup; + } break; case VIR_DOMAIN_CHR_TYPE_SPICEVMC: -- 1.8.3.1

2 1

[libvirt] [PATCH] storage: Check and possibly update config file after build
by John Ferlan 11 Sep '17

11 Sep '17

https://bugzilla.redhat.com/show_bug.cgi?id=1464313 As it turns out, the on-disk config file (e.g. not the stateDir file) needs to be updated when --override is provided since it's possible and highly probable that the def->source.format has been adjusted and could cause a future start after perhaps a libvirtd restart to have the older format from a define operation from the backend. So in the 2 places where it's possible a write would be needed (create after define and build), let's perform a check and do the save/write operation on the configFile if it's necessary. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_driver.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 7cf5943..afb0404 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -651,6 +651,22 @@ storagePoolIsPersistent(virStoragePoolPtr pool) } +/* After a pool build, it's possible the inactive configFile needs to + * be updated especially since overwriting the pool more than likely + * changes the source format and may change/update a few other fields. */ +static int +storagePoolBuildCheckUpdateConfig(virStoragePoolObjPtr obj, + unsigned int flags) +{ + int ret = 0; + + if ((flags & VIR_STORAGE_POOL_BUILD_OVERWRITE) && obj->configFile) + ret = virStoragePoolSaveConfig(obj->configFile, obj->def); + + return ret; +} + + static virStoragePoolPtr storagePoolCreateXML(virConnectPtr conn, const char *xml, @@ -916,6 +932,9 @@ storagePoolCreate(virStoragePoolPtr pool, if (backend->buildPool(pool->conn, obj, build_flags) < 0) goto cleanup; } + + if (storagePoolBuildCheckUpdateConfig(obj, build_flags) < 0) + goto cleanup; } VIR_INFO("Starting up storage pool '%s'", obj->def->name); @@ -980,6 +999,10 @@ storagePoolBuild(virStoragePoolPtr pool, if (backend->buildPool && backend->buildPool(pool->conn, obj, flags) < 0) goto cleanup; + + if (storagePoolBuildCheckUpdateConfig(obj, flags) < 0) + goto cleanup; + ret = 0; cleanup: -- 2.9.5

2 4

[libvirt] [PATCH 0/3] typo fixes
by Guido Günther 11 Sep '17

11 Sep '17

Probably could have gone by the trivial rule. Guido Günther (3): storagefile: fix defintion vs definition typo qemu_driver: fix existance vs existence typo virnetserver: fix mesage vs message typo src/qemu/qemu_driver.c | 2 +- src/rpc/virnetserver.c | 2 +- src/util/virstoragefile.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) -- 2.14.1

2 5

[libvirt] [PATCH] qemu: Provide default LUN=0 for iSCSI if not provided
by John Ferlan 11 Sep '17

11 Sep '17

https://bugzilla.redhat.com/show_bug.cgi?id=1477880 If the "/#" is missing from the provided iSCSI path, then we need to provide the default LUN of /0; otherwise, QEMU will fail to parse the URL causing a failure to either create the guest or hotplug attach the storage. Alter the command lines generated appropriately. This change does not effect the XML input files. One 'side effect' of this for the argv2xml is that if a "/0" is found on the command line, then the generated XML would need to add the "/0" to the output XML since it wouldn't be known whether it existed or not at qemu process creation time. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- NB: Investigated the history quite a bit between QEMU and libiscsi and it seems as though this probably never worked and of course never "tested" in a real environment. Ironically, in qapi/block-core.json, it is claimed that the LUN would default to 0, but the block/iscsi.c code that calls iscsi_parse_full_url would never (AFAICT) have supported not supplying some LUN on the command line. src/qemu/qemu_command.c | 20 ++++++++++++++++---- .../qemuargv2xml-disk-drive-network-iscsi.args | 2 +- .../qemuargv2xml-disk-drive-network-iscsi.xml | 2 +- .../qemuxml2argv-disk-drive-network-iscsi-lun.args | 2 +- .../qemuxml2argv-disk-drive-network-iscsi.args | 2 +- .../qemuxml2argv-hostdev-scsi-lsi-iscsi.args | 2 +- .../qemuxml2argv-hostdev-scsi-virtio-iscsi.args | 2 +- 7 files changed, 22 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index ed8cb6e..cff84de 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -830,10 +830,22 @@ qemuBuildNetworkDriveURI(virStorageSourcePtr src, src->volume, src->path) < 0) goto cleanup; } else { - if (virAsprintf(&uri->path, "%s%s", - src->path[0] == '/' ? "" : "/", - src->path) < 0) - goto cleanup; + if (src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI && + !strchr(src->path, '/')) { + + /* The details of iqn is defined by RFC 3720 and 3721, but + * we just need to make sure there's a lun provided. If not + * provided, then default to zero. If ISCSI LUN is provided + * by /dev/disk/by-path/... , then that path will have the + * specific lun requested. */ + if (virAsprintf(&uri->path, "/%s/0", src->path) < 0) + goto cleanup; + } else { + if (virAsprintf(&uri->path, "%s%s", + src->path[0] == '/' ? "" : "/", + src->path) < 0) + goto cleanup; + } } } diff --git a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.args b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.args index 62cc5c0..ec2e8dc 100644 --- a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.args +++ b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.args @@ -16,7 +16,7 @@ QEMU_AUDIO_DRV=none \ -no-acpi \ -boot c \ -usb \ --drive file=iscsi://example.org:6000/iqn.1992-01.com.example,format=raw,\ +-drive file=iscsi://example.org:6000/iqn.1992-01.com.example/0,format=raw,\ if=virtio \ -drive file=iscsi://example.org:6000/iqn.1992-01.com.example/1,format=raw,\ if=virtio \ diff --git a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml index 23542fa..694412b 100644 --- a/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml +++ b/tests/qemuargv2xmldata/qemuargv2xml-disk-drive-network-iscsi.xml @@ -16,7 +16,7 @@ <emulator>/usr/bin/qemu-system-i686</emulator> <disk type='network' device='disk'> <driver name='qemu' type='raw'/> - <source protocol='iscsi' name='iqn.1992-01.com.example'> + <source protocol='iscsi' name='iqn.1992-01.com.example/0'> <host name='example.org' port='6000'/> </source> <target dev='vda' bus='virtio'/> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args index b25f3a0..0fbfd9a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-lun.args @@ -21,7 +21,7 @@ server,nowait \ -boot c \ -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 \ -usb \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,format=raw,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,format=raw,\ if=none,id=drive-scsi0-0-0-0 \ -device scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args index a1d93af..ed15fda 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi.args @@ -19,7 +19,7 @@ server,nowait \ -no-acpi \ -boot c \ -usb \ --drive file=iscsi://example.org:6000/iqn.1992-01.com.example,format=raw,\ +-drive file=iscsi://example.org:6000/iqn.1992-01.com.example/0,format=raw,\ if=none,id=drive-virtio-disk0 \ -device virtio-blk-pci,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,\ id=virtio-disk0 \ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args index 43c555a..07ae9f5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-lsi-iscsi.args @@ -22,7 +22,7 @@ server,nowait \ -usb \ -drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-ide0-0-0 \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,if=none,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,if=none,\ format=raw,id=drive-hostdev0 \ -device scsi-generic,bus=scsi0.0,scsi-id=4,drive=drive-hostdev0,id=hostdev0 \ -drive file=iscsi://example.org:3260/iqn.1992-01.com.example/1,if=none,\ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args index a78e309..d80c859 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi.args @@ -22,7 +22,7 @@ server,nowait \ -usb \ -drive file=/dev/HostVG/QEMUGuest2,format=raw,if=none,id=drive-ide0-0-0 \ -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ --drive file=iscsi://example.org:3260/iqn.1992-01.com.example,if=none,\ +-drive file=iscsi://example.org:3260/iqn.1992-01.com.example/0,if=none,\ format=raw,id=drive-hostdev0 \ -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=2,lun=4,\ drive=drive-hostdev0,id=hostdev0 \ -- 2.9.5

3 3

[libvirt] [PATCH] virsh: delete "id" for domrename OPTIONS
by Yanqiu Zhang 11 Sep '17

11 Sep '17

"domrename" is used to rename an inactive domain, should not use id for the --domain OPTION. --- tools/virsh-domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index f235c66..84c8dcc 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10151,7 +10151,7 @@ static const vshCmdInfo info_domrename[] = { }; static const vshCmdOptDef opts_domrename[] = { - VIRSH_COMMON_OPT_DOMAIN_FULL, + VIRSH_COMMON_OPT_DOMAIN(N_("domain name or uuid")), {.name = "new-name", .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, -- 1.8.3.1

2 1

[libvirt] [PATCH] qemu: Don't report failure to destroy a destroyed domain
by Jiri Denemark 11 Sep '17

11 Sep '17

When destroying a domain libvirt marks it internally with a beingDestroyed flag to make sure the qemuDomainDestroyFlags API itself cleans up after the domain rather than letting an uninformed EOF handler do it. However, when the domain is being started at the moment libvirt was asked to destroy it, only the starting thread can properly clean up after the domain and thus it ignores the beingDestroyed flag. Once qemuDomainDestroyFlags finally gets a job, the domain may not be running anymore, which should not be reported as an error if the domain has been starting up. https://bugzilla.redhat.com/show_bug.cgi?id=1445600 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6255d89310..a25daae866 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -2224,6 +2224,9 @@ qemuDomainDestroyFlags(virDomainPtr dom, virObjectEventPtr event = NULL; qemuDomainObjPrivatePtr priv; unsigned int stopFlags = 0; + int state; + int reason; + bool starting; virCheckFlags(VIR_DOMAIN_DESTROY_GRACEFUL, -1); @@ -2235,13 +2238,29 @@ qemuDomainDestroyFlags(virDomainPtr dom, if (virDomainDestroyFlagsEnsureACL(dom->conn, vm->def) < 0) goto cleanup; + if (!virDomainObjIsActive(vm)) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("domain is not running")); + goto cleanup; + } + + state = virDomainObjGetState(vm, &reason); + starting = (state == VIR_DOMAIN_PAUSED && + reason == VIR_DOMAIN_PAUSED_STARTING_UP && + !priv->beingDestroyed); + if (qemuProcessBeginStopJob(driver, vm, QEMU_JOB_DESTROY, !(flags & VIR_DOMAIN_DESTROY_GRACEFUL)) < 0) goto cleanup; if (!virDomainObjIsActive(vm)) { - virReportError(VIR_ERR_OPERATION_INVALID, - "%s", _("domain is not running")); + if (starting) { + VIR_DEBUG("Domain %s is not running anymore", vm->def->name); + ret = 0; + } else { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("domain is not running")); + } goto endjob; } -- 2.14.1

2 1

[libvirt] [PATCH v6 00/13] Add support for Veritas HyperScale (VxHS) block device protocol
by John Ferlan 11 Sep '17

11 Sep '17

Here's the reworked v5 series I promised: https://www.redhat.com/archives/libvir-list/2017-August/thread.html Each of the patches lists changes that I recall making in the area. I may have missed a few... and I may have missed something from my own review - so hopefully Ashish you can keep me honest and of course since you have the environment, please check/test that things actually work. I've done quite a bit of reformatting the order and splitting things up so that XML changes are in one patch and qemu changes are in a subsequent patch. Not too little change, but not too excessive. I think we do need to think about the default TLS environment and whether we really care to fail in the event that cfg->vxhsTLS = 0 and src->haveTLS = yes. Ashish Mittal (10): storage: Introduce VIR_STORAGE_NET_PROTOCOL_VXHS docs: Add schema and docs for Veritas HyperScale (VxHS) util: storage: Add JSON backing volume parse for VxHS qemu: Add qemu command line generation for a VxHS block device conf: Introduce TLS options for VxHS block device clients util: Add haveTLS to virStorageSource util: Add virstoragetest to parse/format a tls='yes' qemu: Add TLS support for Veritas HyperScale (VxHS) tests: Add test for failure when vxhs_tls=0 tests: Add a test case for multiple VxHS disk configuration John Ferlan (3): qemu: Add QEMU 2.10 x86_64 the generated capabilities qemu: Detect support for vxhs qemu: Introduce qemuDomainPrepareDiskSource docs/formatdomain.html.in | 46 +- docs/schemas/domaincommon.rng | 18 + src/conf/domain_conf.c | 19 + src/libxl/libxl_conf.c | 1 + src/qemu/libvirtd_qemu.aug | 4 + src/qemu/qemu.conf | 33 + src/qemu/qemu_block.c | 70 +- src/qemu/qemu_block.h | 4 +- src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 41 +- src/qemu/qemu_conf.c | 16 + src/qemu/qemu_conf.h | 3 + src/qemu/qemu_domain.c | 58 + src/qemu/qemu_domain.h | 5 + src/qemu/qemu_driver.c | 3 + src/qemu/qemu_parse_command.c | 15 + src/qemu/qemu_process.c | 4 + src/qemu/test_libvirtd_qemu.aug.in | 2 + src/util/virstoragefile.c | 54 +- src/util/virstoragefile.h | 4 + src/xenconfig/xen_xl.c | 1 + .../caps_2.10.0.x86_64.replies | 17994 +++++++++++++++++++ tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 792 + tests/qemucapabilitiestest.c | 1 + ...ml2argv-disk-drive-network-tlsx509-err-vxhs.xml | 34 + ...-disk-drive-network-tlsx509-multidisk-vxhs.args | 43 + ...v-disk-drive-network-tlsx509-multidisk-vxhs.xml | 50 + ...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 30 + ...emuxml2argv-disk-drive-network-tlsx509-vxhs.xml | 32 + .../qemuxml2argv-disk-drive-network-vxhs.args | 27 + .../qemuxml2argv-disk-drive-network-vxhs.xml | 32 + tests/qemuxml2argvtest.c | 10 + ...uxml2xmlout-disk-drive-network-tlsx509-vxhs.xml | 34 + .../qemuxml2xmlout-disk-drive-network-vxhs.xml | 34 + tests/qemuxml2xmltest.c | 2 + tests/virstoragetest.c | 23 + 37 files changed, 19534 insertions(+), 12 deletions(-) create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-err-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-multidisk-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-tlsx509-vxhs.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-tlsx509-vxhs.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-network-vxhs.xml -- 2.9.5

4 39

[libvirt] [PATCH] virsh: migrate --timeout-postcopy requires --postcopy
by Jiri Denemark 11 Sep '17

11 Sep '17

Requesting an automated switch to a post-copy migration (using --timeout-postcopy) without actually enabling post-copy migration (using --postcopy) doesn't really do anything. Let's make this dependency explicit to avoid unexpected behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1455023 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tools/virsh-domain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index f235c66b07..a3f3b7c7bd 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10768,6 +10768,7 @@ cmdMigrate(vshControl *ctl, const vshCmd *cmd) VSH_EXCLUSIVE_OPTIONS("live", "offline"); VSH_EXCLUSIVE_OPTIONS("timeout-suspend", "timeout-postcopy"); VSH_REQUIRE_OPTION("postcopy-after-precopy", "postcopy"); + VSH_REQUIRE_OPTION("timeout-postcopy", "postcopy"); VSH_REQUIRE_OPTION("persistent-xml", "persistent"); if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) -- 2.14.1

2 1

[libvirt] [PATCH] virsh: help: Drop 'id' from possible values for <domain> argument
by Erik Skultety 11 Sep '17

11 Sep '17

At the moment, we can only rename inactive domains. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490164 Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- Theoretically, we could also remove this check from qemu_driver.c as it's a useless check, given that a VM which passes the 'active' check is going to be a persistent domain: if (!vm->persistent) { virReportError(VIR_ERR_OPERATION_INVALID, "%s", _("cannot rename a transient domain")); goto endjob; } Also, virshCommandOptDomainBy could be used instead of virshCommandOptDomain in this case, but we might as well enable rename for active domains as well, who knows and I don't think this is worth any more attention that just a help string tweak. tools/virsh-domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index f235c66b0..84c8dccae 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10151,7 +10151,7 @@ static const vshCmdInfo info_domrename[] = { }; static const vshCmdOptDef opts_domrename[] = { - VIRSH_COMMON_OPT_DOMAIN_FULL, + VIRSH_COMMON_OPT_DOMAIN(N_("domain name or uuid")), {.name = "new-name", .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, -- 2.13.3

2 2

[libvirt] [PATCH v3 0/4] numa: describe sibling nodes distances
by Wim Ten Have 11 Sep '17

11 Sep '17

From: Wim ten Have <wim.ten.have(a)oracle.com> This patch extents guest domain administration adding support to advertise node sibling distances when configuring HVM numa guests. NUMA (non-uniform memory access), a method of configuring a cluster of nodes within a single multiprocessing system such that it shares processor local memory amongst others improving performance and the ability of the system to be expanded. A NUMA system could be illustrated as shown below. Within this 4-node system, every socket is equipped with its own distinct memory. The whole typically resembles a SMP (symmetric multiprocessing) system being a "tightly-coupled," "share everything" system in which multiple processors are working under a single operating system and can access each others' memory over multiple "Bus Interconnect" paths. +-----+-----+-----+ +-----+-----+-----+ | M | CPU | CPU | | CPU | CPU | M | | E | | | | | | E | | M +- Socket0 -+ +- Socket3 -+ M | | O | | | | | | O | | R | CPU | CPU <---------> CPU | CPU | R | | Y | | | | | | Y | +-----+--^--+-----+ +-----+--^--+-----+ | | | Bus Interconnect | | | +-----+--v--+-----+ +-----+--v--+-----+ | M | | | | | | M | | E | CPU | CPU <---------> CPU | CPU | E | | M | | | | | | M | | O +- Socket1 -+ +- Socket2 -+ O | | R | | | | | | R | | Y | CPU | CPU | | CPU | CPU | Y | +-----+-----+-----+ +-----+-----+-----+ In contrast there is the limitation of a flat SMP system, not illustrated. Here, as sockets are added, the bus (data and address path), under high activity, gets overloaded and easily becomes a performance bottleneck. NUMA adds an intermediate level of memory shared amongst a few cores per socket as illustrated above, so that data accesses do not have to travel over a single bus. Unfortunately the way NUMA does this adds its own limitations. This, as visualized in the illustration above, happens when data is stored in memory associated with Socket2 and is accessed by a CPU (core) in Socket0. The processors use the "Bus Interconnect" to create gateways between the sockets (nodes) enabling inter-socket access to memory. These "Bus Interconnect" hops add data access delays when a CPU (core) accesses memory associated with a remote socket (node). For terminology we refer to sockets as "nodes" where access to each others' distinct resources such as memory make them "siblings" with a designated "distance" between them. A specific design is described under the ACPI (Advanced Configuration and Power Interface Specification) within the chapter explaining the system's SLIT (System Locality Distance Information Table). These patches extend core libvirt's XML description of a virtual machine's hardware to include NUMA distance information for sibling nodes, which is then passed to Xen guests via libxl. Recently qemu landed support for constructing the SLIT since commit 0f203430dd ("numa: Allow setting NUMA distance for different NUMA nodes"), hence these core libvirt extensions can also help other drivers in supporting this feature. The XML changes made allow to describe the <cell> (or node/sockets) <distances> amongst <sibling> node identifiers and propagate these towards the numa domain functionality finally adding support to libxl. [below is an example illustrating a 4 node/socket <cell> setup] <cpu> <numa> <cell id='0' cpus='0,4-7' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='10'/> <sibling id='1' value='21'/> <sibling id='2' value='31'/> <sibling id='3' value='41'/> </distances> </cell> <cell id='1' cpus='1,8-10,12-15' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='21'/> <sibling id='1' value='10'/> <sibling id='2' value='21'/> <sibling id='3' value='31'/> </distances> </cell> <cell id='2' cpus='2,11' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='31'/> <sibling id='1' value='21'/> <sibling id='2' value='10'/> <sibling id='3' value='21'/> </distances> </cell> <cell id='3' cpus='3' memory='2097152' unit='KiB'> <distances> <sibling id='0' value='41'/> <sibling id='1' value='31'/> <sibling id='2' value='21'/> <sibling id='3' value='10'/> </distances> </cell> </numa> </cpu> By default on libxl, if no <distances> are given to describe the SLIT data between different <cell>s, this patch will default to a scheme using 10 for local and 21 for any remote node/socket, which is the assumption of guest OS when no SLIT is specified. While SLIT is optional, libxl requires that distances are set nonetheless. On Linux systems the SLIT detail can be listed with help of the 'numactl -H' command. An above HVM guest as described would on such prompt with below output. [root@f25 ~]# numactl -H available: 4 nodes (0-3) node 0 cpus: 0 4 5 6 7 node 0 size: 1988 MB node 0 free: 1743 MB node 1 cpus: 1 8 9 10 12 13 14 15 node 1 size: 1946 MB node 1 free: 1885 MB node 2 cpus: 2 11 node 2 size: 2011 MB node 2 free: 1912 MB node 3 cpus: 3 node 3 size: 2010 MB node 3 free: 1980 MB node distances: node 0 1 2 3 0: 10 21 31 41 1: 21 10 21 31 2: 31 21 10 21 3: 41 31 21 10 Wim ten Have (4): numa: describe siblings distances within cells libxl: vnuma support xenconfig: add domxml conversions for xen-xl xlconfigtest: add tests for numa cell sibling distances docs/formatdomain.html.in | 70 ++++- docs/schemas/basictypes.rng | 9 + docs/schemas/cputypes.rng | 18 ++ src/conf/cpu_conf.c | 2 +- src/conf/numa_conf.c | 323 +++++++++++++++++++- src/conf/numa_conf.h | 25 +- src/libvirt_private.syms | 6 + src/libxl/libxl_conf.c | 120 ++++++++ src/libxl/libxl_driver.c | 3 +- src/xenconfig/xen_xl.c | 333 +++++++++++++++++++++ .../test-fullvirt-vnuma-nodistances.cfg | 26 ++ .../test-fullvirt-vnuma-nodistances.xml | 53 ++++ tests/xlconfigdata/test-fullvirt-vnuma.cfg | 26 ++ tests/xlconfigdata/test-fullvirt-vnuma.xml | 81 +++++ tests/xlconfigtest.c | 4 + 15 files changed, 1089 insertions(+), 10 deletions(-) create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.xml -- 2.9.5

4 12

[libvirt] [PATCH 0/2] Tiny adjustments to the virsh's man page
by Erik Skultety 08 Sep '17

08 Sep '17

*** BLURB HERE, BLURB THERE, BLURB EVERYWHERE :) *** Erik Skultety (2): virsh: man: Be more explicit about 'create' creating transient domain virsh: man: Document the --validate option for create and define cmds tools/virsh.pod | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) -- 2.13.3

2 5

[libvirt] [PATCH] docs: Update --timeout description in libvirtd's man page
by Erik Skultety 08 Sep '17

08 Sep '17

Since commit @ae2163f8, only active client connections or running domains are allowed to inhibit daemon shutdown. The man page however wasn't updated appropriately. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325066 Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- daemon/libvirtd.pod | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.pod b/daemon/libvirtd.pod index 9f5a17d9c..8d3fbd13d 100644 --- a/daemon/libvirtd.pod +++ b/daemon/libvirtd.pod @@ -56,10 +56,8 @@ Use this name for the PID file, overriding the default value. =item B<-t, --timeout> I<SECONDS> -Exit after timeout period (in seconds) elapse with no client connections -or registered resources. Be aware that resources such as autostart -networks will result in never reaching the timeout, even when there are -no client connections. +Exit after timeout period (in seconds), provided there are neither any client +connections nor any running domains. =item B<-v, --verbose> -- 2.13.3

2 1

[libvirt] [PATCH] cpu: Add new EPYC CPU model
by Brijesh Singh 07 Sep '17

07 Sep '17

Add a new CPU model called 'EPYC' to model processors from AMD EPYC family (which includes EPYC 76xx,75xx,74xx, 73xx and 72xx). The following features bits have been added/removed compare to Opteron_G5 Added: monitor, movbe, rdrand, mmxext, ffxsr, rdtscp, cr8legacy, osvw, fsgsbase, bmi1, avx2, smep, bmi2, rdseed, adx, smap, clfshopt, sha xsaveopt, xsavec, xgetbv1, arat Removed: xop, fma4, tbm The patch is depend on EPYC CPU model supported introduced in qemu [1] [1] https://patchwork.kernel.org/patch/9902205/ Cc: Tom Lendacky <Thomas.Lendacky(a)amd.com> Signed-off-by: Brijesh Singh <brijesh.singh(a)amd.com> --- src/cpu/cpu_map.xml | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 8e7ac49..522d66b 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -251,6 +251,9 @@ <feature name='clflushopt'> <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x00800000'/> </feature> + <feature name='sha_ni'> + <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x20000000'/> + </feature> <feature name='avx512pf'> <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x04000000'/> </feature> @@ -1545,6 +1548,77 @@ <feature name='xop'/> <feature name='xsave'/> </model> + + <model name='EPYC'> + <signature family='23' model='1'/> + <vendor name='AMD'/> + <feature name='sse2'/> + <feature name='sse'/> + <feature name='fxsr'/> + <feature name='mmx'/> + <feature name='clflush'/> + <feature name='pse36'/> + <feature name='pat'/> + <feature name='cmov'/> + <feature name='mca'/> + <feature name='pge'/> + <feature name='mtrr'/> + <feature name='sep'/> + <feature name='apic'/> + <feature name='cx8'/> + <feature name='mce'/> + <feature name='pae'/> + <feature name='msr'/> + <feature name='tsc'/> + <feature name='pse'/> + <feature name='de'/> + <feature name='vme'/> + <feature name='fpu'/> + <feature name='rdrand'/> + <feature name='f16c'/> + <feature name='avx'/> + <feature name='xsave'/> + <feature name='aes'/> + <feature name='popcnt'/> + <feature name='movbe'/> + <feature name='sse4.2'/> + <feature name='sse4.1'/> + <feature name='cx16'/> + <feature name='fma'/> + <feature name='ssse3'/> + <feature name='monitor'/> + <feature name='pclmuldq'/> + <feature name='pni'/> + <feature name='lm'/> + <feature name='rdtscp'/> + <feature name='pdpe1gb'/> + <feature name='fxsr_opt'/> + <feature name='mmxext'/> + <feature name='nx'/> + <feature name='syscall'/> + <feature name='osvw'/> + <feature name='3dnowprefetch'/> + <feature name='misalignsse'/> + <feature name='sse4a'/> + <feature name='abm'/> + <feature name='cr8legacy'/> + <feature name='svm'/> + <feature name='lahf_lm'/> + <feature name='fsgsbase'/> + <feature name='bmi1'/> + <feature name='avx2'/> + <feature name='smep'/> + <feature name='bmi2'/> + <feature name='rdseed'/> + <feature name='adx'/> + <feature name='smap'/> + <feature name='clflushopt'/> + <feature name='sha_ni'/> + <feature name='xsaveopt'/> + <feature name='xsavec'/> + <feature name='xgetbv1'/> + <feature name='arat'/> + </model> </arch> <arch name='ppc64'> -- 2.9.4

3 2

[libvirt] [PATCH v4 00/13] qemu: migration: show disks stats for nbd migration
by Nikolay Shirokovskiy 07 Sep '17

07 Sep '17

diff from v3: ============ 1. Fix misc style issues 2. Use different structure to store mirror stats 3. Drop logic to update mirror stats after mirror become ready This patch series add disks stats to domain job info(stats) as well as to migration completed event in case nbd scheme is used. Patches that were explicitly ACKed in previous review (up to style issues) marked with A. Nikolay Shirokovskiy (13): A qemu: drop code for VIR_DOMAIN_JOB_BOUNDED and timeRemaining A qemu: introduce qemu domain job status A qemu: introduce QEMU_DOMAIN_JOB_STATUS_POSTCOPY A qemu: drop QEMU_MIGRATION_COMPLETED_UPDATE_STATS A qemu: drop excessive zero-out in qemuMigrationFetchJobStatus qemu: refactor fetching migration stats qemu: simplify getting completed job stats A qemu: fail querying destination migration statistics always A qemu: start all async job with job status active A qemu: introduce migrating job status A qemu: always get job condition on getting job stats qemu: migrate: add mirror stats to migration stats A qemu: migration: don't expose incomplete job as complete src/qemu/qemu_domain.c | 69 ++++++++++---- src/qemu/qemu_domain.h | 23 ++++- src/qemu/qemu_driver.c | 86 +++++++++-------- src/qemu/qemu_migration.c | 195 +++++++++++++++++++++++---------------- src/qemu/qemu_migration.h | 14 ++- src/qemu/qemu_migration_cookie.c | 7 +- src/qemu/qemu_process.c | 8 +- 7 files changed, 243 insertions(+), 159 deletions(-) -- 1.8.3.1

2 16

[libvirt] [PATCH] tpm: Use /dev/null for cancel path if none was found
by Stefan Berger 07 Sep '17

07 Sep '17

TPM 2 does not implement sysfs files for cancellation of commands. We therefore use /dev/null for the cancel path passed to QEMU. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- src/util/virtpm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 6d9b065..d5c10da 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -61,9 +61,7 @@ virTPMCreateCancelPath(const char *devpath) VIR_FREE(path); } if (!path) - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("No usable sysfs TPM cancel file could be " - "found")); + ignore_value(VIR_STRDUP(path, "/dev/null")); } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("TPM device path %s is invalid"), devpath); -- 2.5.5

5 6

[libvirt] [PATCH v2 0/3] Add new EPYC CPU model
by Jiri Denemark 07 Sep '17

07 Sep '17

Brijesh Singh (1): cpu: Add new EPYC CPU model Jiri Denemark (2): tests: Add CPUID data for AMD Ryzen 7 1800X Eight-Core Processor tests: Add CPUID data for AMD EPYC 7601 32-Core Processor src/cpu/cpu_map.xml | 74 +++++++ tests/cputest.c | 2 + .../x86_64-cpuid-EPYC-7601-32-Core-disabled.xml | 8 + .../x86_64-cpuid-EPYC-7601-32-Core-enabled.xml | 10 + .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 16 ++ .../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 17 ++ .../x86_64-cpuid-EPYC-7601-32-Core-json.xml | 11 + .../x86_64-cpuid-EPYC-7601-32-Core.json | 241 +++++++++++++++++++++ .../cputestdata/x86_64-cpuid-EPYC-7601-32-Core.xml | 54 +++++ ..._64-cpuid-Ryzen-7-1800X-Eight-Core-disabled.xml | 9 + ...6_64-cpuid-Ryzen-7-1800X-Eight-Core-enabled.xml | 10 + ...x86_64-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 16 ++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 17 ++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml | 11 + .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.json | 203 +++++++++++++++++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.xml | 52 +++++ 16 files changed, 751 insertions(+) create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core.json create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7601-32-Core.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.json create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.xml -- 2.14.1

2 4

[libvirt] [PATCH 0/2] Add new EPYC CPU model
by Jiri Denemark 07 Sep '17

07 Sep '17

Brijesh Singh (1): cpu: Add new EPYC CPU model Jiri Denemark (1): tests: Add CPUID data for AMD Ryzen 7 1800X Eight-Core Processor src/cpu/cpu_map.xml | 74 ++++++++ tests/cputest.c | 1 + ..._64-cpuid-Ryzen-7-1800X-Eight-Core-disabled.xml | 9 + ...6_64-cpuid-Ryzen-7-1800X-Eight-Core-enabled.xml | 10 + ...x86_64-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 16 ++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 17 ++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml | 11 ++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.json | 203 +++++++++++++++++++++ .../x86_64-cpuid-Ryzen-7-1800X-Eight-Core.xml | 52 ++++++ 9 files changed, 393 insertions(+) create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.json create mode 100644 tests/cputestdata/x86_64-cpuid-Ryzen-7-1800X-Eight-Core.xml -- 2.14.1

2 4