[libvirt] [PATCH] virDomainDetachDeviceFlags: Clarify update semantics
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1621910
When users want to update a path to a CDROM they tend to
construct a very minimal XML and feed the API with it. This is
not a good practice as it breaks the assumptions the API is built
on. Most notably, leaving an element out should be treated as a
request for removal of the corresponding setting. Just like
leaving out <bandwidth/> clears out any QoS previously set.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libvirt-domain.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index ef460277f7..bd8ca6eff2 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -8318,6 +8318,14 @@ virDomainDetachDeviceFlags(virDomainPtr domain,
* media, altering the graphics configuration such as password,
* reconfiguring the NIC device backend connectivity, etc.
*
+ * The supplied XML description of the device should contain all
+ * the information that are found in corresponding domain XML.
+ * Leaving out any piece of information is treated as request for
+ * its removal, which may be denied. For instance, when users
+ * want to change CDROM media only for live XML, they must
+ * provide live disk XML as found in corresponding live domain
+ * XML with only the disk path changed.
+ *
* Returns 0 in case of success, -1 in case of failure.
*/
int
--
2.16.4
6 years, 7 months
[libvirt] [PATCH] qemu: domain: validate memory access during validate domain config
by Luyao Huang
commit 6534b3c4 try to raise an error when there is no numa nodes but
set access='shared' in domain config. In that commit, we add a memory access
validate function for memory device, but this check is not related to memory
device and won't work if there is no memory device in guest xml.
Move the memory access related check in the domain config validate function,
and simplify the unit test xml to avoid other error.
https://bugzilla.redhat.com/show_bug.cgi?id=1448149#c14
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
src/qemu/qemu_domain.c | 55 +++++++++++-----------
tests/qemuxml2argvdata/hugepages-memaccess3.xml | 62 +------------------------
tests/qemuxml2argvtest.c | 6 +--
3 files changed, 32 insertions(+), 91 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index f570081..f0c461b 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3888,6 +3888,29 @@ qemuDomainDefValidateFeatures(const virDomainDef *def,
static int
+qemuDomainDefValidateMemory(const virDomainDef *def)
+{
+ const long system_page_size = virGetSystemPageSizeKB();
+
+ /* We can't guarantee any other mem.access
+ * if no guest NUMA nodes are defined. */
+ if (def->mem.nhugepages != 0 &&
+ def->mem.hugepages[0].size != system_page_size &&
+ virDomainNumaGetNodeCount(def->numa) == 0 &&
+ def->mem.access != VIR_DOMAIN_MEMORY_ACCESS_DEFAULT &&
+ def->mem.access != VIR_DOMAIN_MEMORY_ACCESS_PRIVATE) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("memory access mode '%s' not supported "
+ "without guest numa node"),
+ virDomainMemoryAccessTypeToString(def->mem.access));
+ return -1;
+ }
+
+ return 0;
+}
+
+
+static int
qemuDomainDefValidate(const virDomainDef *def,
virCapsPtr caps ATTRIBUTE_UNUSED,
void *opaque)
@@ -4009,6 +4032,9 @@ qemuDomainDefValidate(const virDomainDef *def,
if (qemuDomainDefValidateFeatures(def, qemuCaps) < 0)
goto cleanup;
+ if (qemuDomainDefValidateMemory(def) < 0)
+ goto cleanup;
+
ret = 0;
cleanup:
@@ -5531,30 +5557,6 @@ qemuDomainDeviceDefValidateController(const virDomainControllerDef *controller,
static int
-qemuDomainDeviceDefValidateMemory(const virDomainMemoryDef *memory ATTRIBUTE_UNUSED,
- const virDomainDef *def)
-{
- const long system_page_size = virGetSystemPageSizeKB();
-
- /* We can't guarantee any other mem.access
- * if no guest NUMA nodes are defined. */
- if (def->mem.nhugepages != 0 &&
- def->mem.hugepages[0].size != system_page_size &&
- virDomainNumaGetNodeCount(def->numa) == 0 &&
- def->mem.access != VIR_DOMAIN_MEMORY_ACCESS_DEFAULT &&
- def->mem.access != VIR_DOMAIN_MEMORY_ACCESS_PRIVATE) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("memory access mode '%s' not supported "
- "without guest numa node"),
- virDomainMemoryAccessTypeToString(def->mem.access));
- return -1;
- }
-
- return 0;
-}
-
-
-static int
qemuDomainDeviceDefValidateVsock(const virDomainVsockDef *vsock,
const virDomainDef *def,
virQEMUCapsPtr qemuCaps)
@@ -5712,10 +5714,6 @@ qemuDomainDeviceDefValidate(const virDomainDeviceDef *dev,
qemuCaps);
break;
- case VIR_DOMAIN_DEVICE_MEMORY:
- ret = qemuDomainDeviceDefValidateMemory(dev->data.memory, def);
- break;
-
case VIR_DOMAIN_DEVICE_VSOCK:
ret = qemuDomainDeviceDefValidateVsock(dev->data.vsock, def, qemuCaps);
break;
@@ -5737,6 +5735,7 @@ qemuDomainDeviceDefValidate(const virDomainDeviceDef *dev,
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
case VIR_DOMAIN_DEVICE_SHMEM:
+ case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_NONE:
diff --git a/tests/qemuxml2argvdata/hugepages-memaccess3.xml b/tests/qemuxml2argvdata/hugepages-memaccess3.xml
index 8ec38d8..43c3ec6 100644
--- a/tests/qemuxml2argvdata/hugepages-memaccess3.xml
+++ b/tests/qemuxml2argvdata/hugepages-memaccess3.xml
@@ -12,76 +12,18 @@
<type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type>
<bootmenu enable='yes'/>
</os>
- <features>
- <acpi/>
- <apic/>
- <pae/>
- </features>
<cpu mode='host-model' check='partial'>
<model fallback='allow'/>
</cpu>
- <clock offset='variable' adjustment='500' basis='utc'>
- <timer name='rtc' tickpolicy='catchup'/>
- <timer name='pit' tickpolicy='delay'/>
- <timer name='hpet' present='no'/>
- </clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
- <pm>
- <suspend-to-mem enabled='yes'/>
- <suspend-to-disk enabled='yes'/>
- </pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
- <disk type='file' device='disk'>
- <driver name='qemu' type='qcow2' discard='unmap'/>
- <source file='/var/lib/libvirt/images/fedora.qcow2'/>
- <target dev='sda' bus='scsi'/>
- <boot order='1'/>
- <address type='drive' controller='0' bus='0' target='0' unit='0'/>
- </disk>
- <controller type='usb' index='0' model='piix3-uhci'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
- </controller>
+ <controller type='usb' index='0'/>
<controller type='pci' index='0' model='pci-root'/>
- <controller type='scsi' index='0'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
- </controller>
- <controller type='virtio-serial' index='0'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
- </controller>
- <controller type='ide' index='0'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
- </controller>
- <serial type='pty'>
- <target type='isa-serial' port='1'>
- <model name='isa-serial'/>
- </target>
- </serial>
- <console type='pty'>
- <target type='serial' port='1'/>
- </console>
- <channel type='unix'>
- <target type='virtio' name='org.qemu.guest_agent.0'/>
- <address type='virtio-serial' controller='0' bus='0' port='1'/>
- </channel>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
- <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
- <listen type='address' address='0.0.0.0'/>
- </graphics>
- <graphics type='spice'>
- <listen type='socket' socket='/tmp/spice.sock'/>
- </graphics>
- <video>
- <model type='virtio' heads='1' primary='yes'>
- <acceleration accel3d='yes'/>
- </model>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
- </video>
- <memballoon model='virtio'>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
- </memballoon>
+ <memballoon model='none'/>
</devices>
</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 0e9eef6..6b55316 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1023,9 +1023,9 @@ mymain(void)
DO_TEST("hugepages-memaccess2", QEMU_CAPS_OBJECT_MEMORY_FILE,
QEMU_CAPS_OBJECT_MEMORY_RAM, QEMU_CAPS_DEVICE_PC_DIMM,
QEMU_CAPS_NUMA);
- DO_TEST_FAILURE("hugepages-memaccess3",
- QEMU_CAPS_OBJECT_MEMORY_RAM, QEMU_CAPS_OBJECT_MEMORY_FILE,
- QEMU_CAPS_VIRTIO_SCSI);
+ DO_TEST_PARSE_ERROR("hugepages-memaccess3",
+ QEMU_CAPS_OBJECT_MEMORY_RAM,
+ QEMU_CAPS_OBJECT_MEMORY_FILE);
DO_TEST_CAPS_LATEST("hugepages-nvdimm");
DO_TEST("nosharepages", QEMU_CAPS_MEM_MERGE);
DO_TEST("disk-cdrom", NONE);
--
1.8.3.1
6 years, 7 months
[libvirt] [PATCH -v2 0/1] esx: Fix get/set vcpus
by Marcos Paulo de Souza
Hi guys,
this is the second version of the patch, the first one can be found here[1].
This version addresses the comments from Matthias Bolte, making the change
simpler and cleaner.
Let me know if there are other details that needs to change.
[1]: https://www.redhat.com/archives/libvir-list/2018-August/msg00532.html
Marcos Paulo de Souza (1):
esx: Make esxDomainGetVcpusFlags check flags
src/esx/esx_driver.c | 52 ++++++++++++++++++++++++--------------------
1 file changed, 28 insertions(+), 24 deletions(-)
--
2.17.1
6 years, 7 months
[libvirt] [PATCH] vsh-table: Fix broken build on centos and rhel
by Simon Kobyda
The reason of broken build was that centos and rhel use older version of glibc.
These versions of glibc on these platforms cannot work with newer unicodes,
therefore functions iswprint() and wcwidth() failed. So I replaced them with
older unicode characters.
Signed-off-by: Simon Kobyda <skobyda(a)redhat.com>
---
tests/vshtabletest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/vshtabletest.c b/tests/vshtabletest.c
index 1b07c37c56..9e9c045226 100644
--- a/tests/vshtabletest.c
+++ b/tests/vshtabletest.c
@@ -123,7 +123,7 @@ testUnicode(const void *opaque ATTRIBUTE_UNUSED)
" Id 名稱 государство \n"
"-----------------------------------------\n"
" 1 fedora28 running \n"
-" 2 🙊🙉🙈rhel7.5🙆🙆🙅 running \n";
+" 2 つへソrhel7.5つへソ running \n";
vshTablePtr table;
table = vshTableNew("Id", "名稱", "государство", NULL);
@@ -131,7 +131,7 @@ testUnicode(const void *opaque ATTRIBUTE_UNUSED)
goto cleanup;
vshTableRowAppend(table, "1", "fedora28", "running", NULL);
- vshTableRowAppend(table, "2", "🙊🙉🙈rhel7.5🙆🙆🙅", "running",
+ vshTableRowAppend(table, "2", "つへソrhel7.5つへソ", "running",
NULL);
act = vshTablePrintToString(table, true);
--
2.17.1
6 years, 7 months
[libvirt] [PATCH] tests: Properly reset mocked CPU model
by Jiri Denemark
When switching the host architecture to something for which we do not
have any host CPU model defined, the mocked
virQEMUCapsProbeHostCPUForEmulator would just return the previous CPU
model resulting in strange combinations, such as "core2duo" host CPU
model in QEMU capabilities for "AArch64" architecture. It currently
doesn't break any test case, but we should fix it anyway to avoid future
surprises which would be quite hard to debug.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tests/testutilsqemu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 8438613f28..52ea6bf655 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -575,6 +575,8 @@ qemuTestSetHostCPU(virCapsPtr caps,
setenv("VIR_TEST_MOCK_FAKE_HOST_CPU", cpu->model, 1);
else
unsetenv("VIR_TEST_MOCK_FAKE_HOST_CPU");
+ } else {
+ unsetenv("VIR_TEST_MOCK_FAKE_HOST_CPU");
}
caps->host.cpu = cpu;
}
--
2.18.0
6 years, 7 months
[libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
by Laine Stump
(Several of us started an offline discussion on this topic, and it
quickly became complicated, so we decided it should continue upstream.
Here is a synopsis of the discussion so far (as *I've* interpreted it,
so corrections are welcome and apologies in advance for anything I got
wrong!) Some of the things are stated here as givens, but feel free to
rip them apart.)
Summary of the problem:
1) We want to persuade libvirt+QEMU users to move away from the i440fx
machinetype in favor of Q35. (NB: Someday this *might* lead to the
ability to deprecate and even remove the 440fx machinetype, but even if
that were to happen, it would be a *very long* time from now, so this
discussion is *not* about that!)
2) When Q35 machinetype is used, libvirt assigns virtio devices to a
slot on a PCI Express controller (because why have modern PCIe
controllers/slots available but force everything onto clunky old legacy
controllers?).
3) When a virtio device is plugged into an Express controller, QEMU
disables the device's IO port space, and it is put into "modern-only"
mode (this is done to avoid a rapid exhaustion of limited IO port space).
4) modern-only virtio devices won't work with a legacy (virtio-0.9-only)
guest driver, because virtio-0.9 requires IO port space.
5) Some guest OSes that we still want to support (and which would
otherwise work okay on a Q35 virtual machine) have virtio drivers too
old to support virtio-1.0 (CentOS6 and RHEL6 are examples of such OSes),
but due to the chain of reasons listed above, the "standard" config for
a Q35 guest generated by libvirt doesn't support virtio-0.9, hence
doesn't support these guest OSes.
And here's a list of possible solutions to this problem (note that
"consumers" means management applications such as OpenStack, oVirt,
virt-manager, virt-install, gnome-boxes, etc. In all cases, it's assumed
that the consumer's decision on the action to take will be based on
information from libosinfo). For completeness, I've included even the
possibilities that have been rejected, along with a brief synopsis of
(at least part of) the reason for rejection:
(1) Add some way libvirt consumers can ask libvirt to place
virtio devices on a legacy pci slot instead of pcie when
the machinetype is q35 (qemu sets virtio devices in legacy
PCI slots to transitional mode, so io port space is enabled
and virtio-0.0 drivers will work).
This has been proposed on libvir-list, but rejected. Here is
the most elquently stated reasoning for the rejection I could
find (with thanks to Dan Berrange):
The domain XML is a way to express the configuration
of the guest virtual machine. What we're talking about
here is a policy tunable for an internal libvirt QEMU
driver algorithm, as so does not belong anywhere in the
domain XML.
(2) Add full-blown pci enumeration support to all libvirt consumers
(i.e. they will need to build a model of the PCI bus topology
of each guest, and keep track of which addresses are in use).
They can then manually place virtio devices on legacy pci slots
(again, triggering transitional mode) when the intended guest
OS doesn't support virtio-0.9.
(This is seen as requiring too much duplicated effort for
development and support/maintenance, since up until now libvirt
has been the single point of action for PCI address assignment
(well, QEMU can do it too, but for > 10 years libvirt has
*always* provided full PCI addresses for all devices)
(3) Add virtio-1.0 support to all guest OSes. If this is done,
existing libvirt configs will work.
(Aside from the difficulty of backporting, and the fact that
there are going to be some OSes that don't get it *at all*,
there will always be older releases that haven't gotten the
backport. So this isn't a complete solution).
(4) Consumers can continue using the 440fx machinetype for guest
OSes that don't support virtio-0.9
(This would work, but perpetuates use of the 440fx
machinetype, and all for just this one reason (at least in
the case of CentOS6/RHEL6, which otherwise work just fine with
Q35)).
(5) Introduce virtio-0.9, virtio-1.0 models in libvirt
which are explicitly legacy-only and modern-only.
QEMU doesn't need to change, as libvirt can simply set
the right params on existing QEMU models to force the
behavior.
(NB: it's unclear to me whether virtio-0.9 simply won't
work without forcing the device to be on a legacy PCI
slot, or if that's just "a very bad idea" because it
will mean that the device uses up extra io port space)
The offline discussion had basically come to the point of saying that
options (4) and (5) were the only reasonable ones, with option (5) being
preferred (I think).
As a starter for continuing the discussion, it seems to me that for
option (5):
a) we don't really need the virtio-1.0 model, since that's what you
currently get anyway when you ask for "virtio" on Q35 (and on 440fx,
"virtio" gives you transitional, which works for everybody).
b) Rather than a "legacy-only" model for virtio-0.9, it would be more
useful to have "transitional". This way the config would work for older
OSes that don't support virtio-1.0, and when/if the OS was upgraded such
that it supported virtio-1.0, that would be automatically used without
needing to change the config.
c) Even if it's possible to force a device on an Express slot into
transitional mode, this is extremely wasteful of io port space, so
libvirt should consider virtio-0.9 devices to be legacy PCI, and thus
plug them into legacy PCI slots. And once we're doing this, it's
unnecessary to add any extra option to the qemu commandline to force
legacy support (i.e. transitional mode), as that is what QEMU already
does when the device is connected to a legacy PCI slot.
So making the naive assumption that we agree on implementing option (5)
and there are no objections to my points a-c (Hah! As if!), how does
this sound as a plan:
A) libosinfo starts telling consumers that the preferred virtio device
model for the relevant OSes is "virtio-0.9", and leaves the
recommendation for other OSes as "virtio".
B) libvirt adds a "virtio-0.9" model for all virtio devices that
actually have virtio-0.9 support (a couple of devices never existed
prior to virtio-1.0 (rng and ???) so virtio-0.9 would be nonsensical for
them).
C) inside libvirt, the implementation of the "virtio-0.9" model is
identical to "virtio", except that the VIR_PCI_CONNECT_TYPE flags for
these devices contain VIR_PCI_CONNECT_TYPE_PCI rather than
VIR_PCI_CONNECT_TYPE_PCIE, resulting in those devices being assigned to
a legacy PCI slot, and thus they would be transitional mode by default.
(If there is disagreement about putting these devices on a legacy PCI
slot, then (C) could be changed to add "disable-legacy=off" to the qemu
commandline. But again, even if that works, it would use up 4k of IO
port space for each device, causing it to rapidly run out, and I don't
think that should be the default mode of operation).
6 years, 7 months
[libvirt] [PATCH v2 0/8] storage: Resolve some locking issues
by Michal Privoznik
Technically, this is a v2 of:
https://www.redhat.com/archives/libvir-list/2018-August/msg00624.html
but majority of the patches are new. The review of the patch from above
made me look into storage pool locking more and I have found some
issues.
For best view of the patches (esp. 4/8 use --histogram option).
Michal Prívozník (8):
storage_backend_rbd: Drop ATTRIBUTE_UNUSED for arguments that are used
virstorageobj: Move virStoragePoolObjIsDuplicate up
virstorageobj: Check for duplicates from virStoragePoolObjAssignDef
virstorageobj: Move virStoragePoolObjSourceFindDuplicate and friends
up
virStoragePoolObjSourceFindDuplicate: Drop @conn argument
virstorageobj: Check for source duplicates from
virStoragePoolObjAssignDef
storage_driver: Mark volume as 'in use' for some operations
storage_driver: Release pool object lock for some long running jobs
src/conf/virstorageobj.c | 937 +++++++++++++++--------------
src/conf/virstorageobj.h | 13 +-
src/libvirt_private.syms | 2 -
src/storage/storage_backend_iscsi_direct.c | 6 +-
src/storage/storage_backend_rbd.c | 12 +-
src/storage/storage_driver.c | 56 +-
src/test/test_driver.c | 12 +-
7 files changed, 529 insertions(+), 509 deletions(-)
--
2.16.4
6 years, 7 months
[libvirt] [PATCH v4 00/12] PCI passthrough support on s390
by Yi Min Zhao
Abstract
========
The PCI representation in QEMU has recently been extended for S390
allowing configuration of zPCI attributes like uid (user-defined
identifier) and fid (PCI function identifier).
The details can be found here:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
To support the new zPCI feature of the S390 platform, two new XML
attributes, @uid and @fid, are introduced for device addresses of type
'pci', i.e.:
<hostdev mode='subsystem' type='pci'>
<driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'
uid='0x0003' fid='0x00000027'/>
</hostdev>
uid and fid are optional attributes. If they are defined by the user,
unique values within the guest domain must be used. If they are not
specified and the architecture requires them, they are automatically
generated with non-conflicting values.
Current implementation is the most seamless one for the user as it
unites the address specific data of a PCI device on one XML element.
It could accommodate both specifying our special parameters (uid and fid)
and re-using standard statements (domain, bus, slot and function) for
PCI devices. User can still specify bus/slot/function for the virtualized
PCI devices in the XML.
Thus uid/fid act as an extension to the PCI address and are stored in
a new structure 'virZPCIDeviceAddress' which is a member of common PCI
Address structure. Additionally, two hashtables are used for assignment
and reservation of uid/fid.
In support of extending the PCI address, a new PCI address extension flag is
introduced. This extension flag allows is not only dedicated for the S390
platform but also other architectures needing certain extensions to PCI
address space.
Code Base
=========
commit in master:
3b89e1f962 docs: api_extension: Don't encourage other tools than git
Change Log
==========
v3->v4:
1. Update docs.
2. Format code style.
3. Optimize zPCI support check.
4. Move the check of zPCI defined in xml but unsupported by Qemu to
qemuDomainDeviceDefValidate().
5. Change zpci address member of PCI address struct from pointer to
instance.
6. Modify zpci address definition principle. Currently the user must
either define both of uid and fid or not.
v2->v3:
1. Revise code style.
2. Update test cases.
3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI
extension addresses.
4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI
address exists.
5. Optimize zPCI address check logic.
6. Optimize passed parameters of zPCI addr alloc/release/reserve functions.
7. Report enum range error in qemuDomainDeviceSupportZPCI().
8. Update commit messages.
v1->v2:
1. Separate test commit and merge testcases into corresponding commits that
introduce the functionalities firstly.
2. Spare some checks for zpci device.
3. Add vsock and controller support.
4. Add uin32 type schema.
5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid.
6. Always return multibus support on S390.
Yi Min Zhao (12):
conf: Add definitions for 'uid' and 'fid' PCI address attributes
qemu: Introduce zPCI capability
conf: Introduce a new PCI address extension flag
qemu: Enable PCI multi bus for S390 guests
qemu: Auto add pci-root for s390/s390x guests
conf: Introduce address caching for PCI extensions
conf: Introduce parser, formatter for uid and fid
conf: Allocate/release 'uid' and 'fid' in PCI address
qemu: Generate and use zPCI device in QEMU command line
qemu: Add hotpluging support for PCI devices on S390 guests
docs: Add 'uid' and 'fid' information
news: Update news for PCI address extension attributes
cfg.mk | 1 +
docs/formatdomain.html.in | 9 +-
docs/news.xml | 10 +
docs/schemas/basictypes.rng | 23 ++
docs/schemas/domaincommon.rng | 1 +
src/conf/device_conf.c | 62 ++++
src/conf/device_conf.h | 14 +
src/conf/domain_addr.c | 331 +++++++++++++++++++++
src/conf/domain_addr.h | 29 ++
src/conf/domain_conf.c | 6 +
src/libvirt_private.syms | 4 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 95 ++++++
src/qemu/qemu_command.h | 2 +
src/qemu/qemu_domain.c | 27 ++
src/qemu/qemu_domain_address.c | 205 ++++++++++++-
src/qemu/qemu_hotplug.c | 151 +++++++++-
src/util/virpci.h | 11 +
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 +
tests/qemuxml2argvdata/disk-virtio-s390-zpci.args | 26 ++
tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml | 17 ++
.../hostdev-vfio-zpci-autogenerate.args | 25 ++
.../hostdev-vfio-zpci-autogenerate.xml | 18 ++
.../hostdev-vfio-zpci-boundaries.args | 29 ++
.../hostdev-vfio-zpci-boundaries.xml | 26 ++
.../hostdev-vfio-zpci-multidomain-many.args | 39 +++
.../hostdev-vfio-zpci-multidomain-many.xml | 67 +++++
tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 25 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 19 ++
tests/qemuxml2argvtest.c | 20 ++
tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml | 29 ++
.../hostdev-vfio-zpci-autogenerate.xml | 30 ++
.../hostdev-vfio-zpci-boundaries.xml | 42 +++
.../hostdev-vfio-zpci-multidomain-many.xml | 79 +++++
tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 30 ++
tests/qemuxml2xmltest.c | 17 ++
42 files changed, 1518 insertions(+), 14 deletions(-)
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
--
Yi Min
6 years, 7 months
[libvirt] [PATCH] virDomainObjListAddLocked: fix double free
by Marc Hartmayer
If @vm has flagged as "to be removed" virDomainObjListFindByNameLocked
returns NULL (although the definition actually exists). Therefore, the
possibility exits that "virHashAddEntry" will raise the error
"Duplicate key" => virDomainObjListAddObjLocked fails =>
virDomainObjEndAPI(&vm) is called and this leads to a freeing of @def
since @def is already assigned to vm->def. But actually this leads to
a double free since the common usage pattern is that the caller of
virDomainObjListAdd(Locked) is responsible for freeing @def in case of
an error.
Let's fix this by setting vm->def to NULL in case of an error.
Backtrace:
➤ bt
#0 virFree (ptrptr=0x7575757575757575)
#1 0x000003ffb5b25b3e in virDomainResourceDefFree
#2 0x000003ffb5b37c34 in virDomainDefFree
#3 0x000003ff9123f734 in qemuDomainDefineXMLFlags
#4 0x000003ff9123f7f4 in qemuDomainDefineXML
#5 0x000003ffb5cd2c84 in virDomainDefineXML
#6 0x000000011745aa82 in remoteDispatchDomainDefineXML
...
Reviewed-by: Bjoern Walk <bwalk(a)linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay(a)linux.ibm.com>
---
src/conf/virdomainobjlist.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c
index 52171594f34f..805fe9440afe 100644
--- a/src/conf/virdomainobjlist.c
+++ b/src/conf/virdomainobjlist.c
@@ -329,8 +329,10 @@ virDomainObjListAddLocked(virDomainObjListPtr doms,
goto cleanup;
vm->def = def;
- if (virDomainObjListAddObjLocked(doms, vm) < 0)
+ if (virDomainObjListAddObjLocked(doms, vm) < 0) {
+ vm->def = NULL;
goto error;
+ }
}
cleanup:
return vm;
--
2.13.4
6 years, 7 months
[libvirt] [PATCH v3] virsh: Don't break loop of domblkinfo for disks
by Han Han
Fix logical error in v2: https://www.redhat.com/archives/libvir-list/2018-August/msg01358.html
https://bugzilla.redhat.com/show_bug.cgi?id=1619625
--all option is added to cmdDomblkinfo since commit 62c39193 allowing to
show all block devices info. Reset error when empty source in case error
breaks the loop of domblkinfo for disks.
Signed-off-by: Han Han <hhan(a)redhat.com>
---
tools/virsh-domain-monitor.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
index b9b4f9739b..ecb98d4128 100644
--- a/tools/virsh-domain-monitor.c
+++ b/tools/virsh-domain-monitor.c
@@ -475,6 +475,7 @@ cmdDomblkinfo(vshControl *ctl, const vshCmd *cmd)
int ndisks;
size_t i;
xmlNodePtr *disks = NULL;
+ char *source = NULL;
char *target = NULL;
char *protocol = NULL;
@@ -505,18 +506,20 @@ cmdDomblkinfo(vshControl *ctl, const vshCmd *cmd)
for (i = 0; i < ndisks; i++) {
ctxt->node = disks[i];
+ source = virXPathString("string(./source)", ctxt);
protocol = virXPathString("string(./source/@protocol)", ctxt);
target = virXPathString("string(./target/@dev)", ctxt);
rc = virDomainGetBlockInfo(dom, target, &info, 0);
if (rc < 0) {
- /* If protocol is present that's an indication of a networked
- * storage device which cannot provide statistics, so generate
- * 0 based data and get the next disk. */
- if (protocol && !active &&
+ /* For the case of empty cdrom, networked disk which cannot
+ * provide statistics, generate 0 based data and get the next
+ * disk.
+ */
+ if (!source || (protocol && !active &&
virGetLastErrorCode() == VIR_ERR_INTERNAL_ERROR &&
- virGetLastErrorDomain() == VIR_FROM_STORAGE) {
+ virGetLastErrorDomain() == VIR_FROM_STORAGE)) {
memset(&info, 0, sizeof(info));
vshResetLibvirtError();
} else {
@@ -526,6 +529,7 @@ cmdDomblkinfo(vshControl *ctl, const vshCmd *cmd)
cmdDomblkinfoPrint(ctl, &info, target, human, false);
+ VIR_FREE(source);
VIR_FREE(target);
VIR_FREE(protocol);
}
@@ -540,6 +544,7 @@ cmdDomblkinfo(vshControl *ctl, const vshCmd *cmd)
cleanup:
virshDomainFree(dom);
+ VIR_FREE(source);
VIR_FREE(target);
VIR_FREE(protocol);
VIR_FREE(disks);
--
2.18.0
6 years, 7 months
