Re: [libvirt] [PATCH v3 0/8] CPU Model Baseline and Comparison for s390x
Polite ping. I'd like to at least make sure these patches are on the right track with what libvirt expects for these commands. :) On 5/30/19 10:23 AM, Collin Walling wrote: Changelog: v2 - numerous cleanups - removed "policy fix function" and now properly check for policy == -1 in the CPUDef -> JSON parser - resolved some memory leaks - added string arg to qemuMonitorJSONParseCPUModelData for error message to print out proper command name v1 - introduce baseline - split patches into small chunks - free'd lingering qemuMonitorCPUModelInfo pointer - when converting from virCPUDef -> virJSON, consider feature policy FORCED for enabled ___ To run these patches, execute the virsh hypervisor-cpu-compare or hypervisor-cpu-baseline commands and pass an XML file describing one or more CPU definition. You can use the definition from virsh domcapabilities or from a guest XML. There is no need extract it from the file and place it a new one, as the XML parser will look specifically for the CPU tags. ___ These patches hookup the virsh hypervisor-cpu-compare/baseline commands for the s390x architecture. They take an XML file describing some CPU definitions and passes the data to QEMU, where the actual CPU model comparison / baseline calculation is handled (available since QEMU 2.8.5). These calculations are compared against / baselined with the hypervisor CPU model, which can be observed via the virsh domcapabilities command for s390x. When baselining CPU models and the user appends the --features argument to the command, s390x will only report back features that supersede the base model definition. **NOTE** if the --features flag is intended to expand ALL features available to a CPU model (such as the huge list of features reported by a full CPU model expansion), please let me know and I can resolve this. The first patch pulls some code out of the CPU Model Expansion JSON function so that it can be later used for the Comparison and Baseline JSON functions. The rest of the patches follow this sequence: - introduce JSON monitor functions - introduce capability and update test files - hook up monitor functions to virsh command Patch 7 pulls out some code from the CPUDef XML parser to be reused in the comparison hookup. Thanks. x86 and Power review by Daniel Henrique Barboza (thanks!) Collin Walling (8): qemu_monitor: helper functions for CPU models qemu_monitor: implement query-cpu-model-baseline qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE qemu_driver: hook up query-cpu-model-baseline qemu_monitor: implement query-cpu-model-comparison qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON cpu_conf: xml to cpu definition parse helper qemu_driver: hook up query-cpu-model-comparison src/conf/cpu_conf.c | 30 +++ src/conf/cpu_conf.h | 6 + src/cpu/cpu.c| 14 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 138 +++ src/qemu/qemu_capabilities.h | 20 ++ src/qemu/qemu_driver.c | 38 +++ src/qemu/qemu_monitor.c | 44 src/qemu/qemu_monitor.h | 18 ++ src/qemu/qemu_monitor_json.c | 297 --- src/qemu/qemu_monitor_json.h | 20 ++ tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 + 18 files changed, 591 insertions(+), 49 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/3] tests: Include LDADDS in qemu_LDADDS
On Wed, 2019-06-12 at 10:53 -0600, Jim Fehlig wrote: > On 6/12/19 5:19 AM, Andrea Bolognani wrote: > > Finally got around to implement the suggestion I made in > > > >https://www.redhat.com/archives/libvir-list/2019-May/msg00894.html > > > > Andrea Bolognani (3): > >tests: Tweak cputest_LDADDS > >tests: Tweak vircapstest_LDADD > >tests: Include LDADDS in qemu_LDADDS > > > > tests/Makefile.am | 44 +--- > > 1 file changed, 25 insertions(+), 19 deletions(-) > > In addition to reviewing these changes, I also tested them in my LTO build > setup. Other than the commit message nit in patch 1, looks good! Neat! I've fixed the commit message and pushed the series. Thanks for testing and reviewing :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Add support for overriding max threads per process limit
On 6/6/19 11:40 AM, Jim Fehlig wrote:
Some VM configurations may result in a large number of threads created by
the associated qemu process which can exceed the system default limit. The
maximum number of threads allowed per process is controlled by the pids
cgroup controller and is set to 16k when creating VMs with systemd's
machined service. The maximum number of threads per process is recorded
in the pids.max file under the machine's pids controller cgroup hierarchy,
e.g.
$cgrp-mnt/pids/machine.slice/machine-qemu\\x2d1\\x2dtest.scope/pids.max
Maximum threads per process is controlled with the TasksMax property of
the systemd scope for the machine. This patch adds an option to qemu.conf
which can be used to override the maximum number of threads allowed per
qemu process. If the value of option is greater than zero, it will be set
in the TasksMax property of the machine's scope after creating the machine.
Signed-off-by: Jim Fehlig
---
src/lxc/lxc_cgroup.c | 1 +
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf | 10 ++
src/qemu/qemu_cgroup.c | 1 +
src/qemu/qemu_conf.c | 2 ++
src/qemu/qemu_conf.h | 1 +
src/qemu/test_libvirtd_qemu.aug.in | 1 +
src/util/vircgroup.c | 6 +-
src/util/vircgroup.h | 1 +
src/util/virsystemd.c | 24 +++-
src/util/virsystemd.h | 3 ++-
tests/virsystemdtest.c | 12 ++--
12 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
index d93a19d684..76014f3bfd 100644
--- a/src/lxc/lxc_cgroup.c
+++ b/src/lxc/lxc_cgroup.c
@@ -455,6 +455,7 @@ virCgroupPtr virLXCCgroupCreate(virDomainDefPtr def,
nnicindexes, nicindexes,
def->resource->partition,
-1,
+0,
&cgroup) < 0)
goto cleanup;
diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index b311f02da6..c70b903fed 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -94,6 +94,7 @@ module Libvirtd_qemu =
| limits_entry "max_core"
| bool_entry "dump_guest_core"
| str_entry "stdio_handler"
+ | int_entry "max_threads_per_process"
let device_entry = bool_entry "mac_filter"
| bool_entry "relaxed_acs_check"
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index 5a85789d81..ab044c9cf3 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -608,6 +608,16 @@
#max_processes = 0
#max_files = 0
+# If max_threads_per_process is set to a positive integer, libvirt
+# will use it to set the maximum number of threads that can be
+# created by a qemu process. Some VM configurations can result in
+# qemu processes with tens of thousands of threads. systemd-based
+# systems typically limit the number of threads per process to
+# 16k. max_threads_per_process can be used to override default
+# limits in the host OS.
+#
+#max_threads_per_process = 0
+
# If max_core is set to a non-zero integer, then QEMU will be
# permitted to create core dumps when it crashes, provided its
# RAM size is smaller than the limit set.
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index ca76c4fdfa..9603f33e8a 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -930,6 +930,7 @@ qemuInitCgroup(virDomainObjPtr vm,
nnicindexes, nicindexes,
vm->def->resource->partition,
cfg->cgroupControllers,
+cfg->maxThreadsPerProc,
&priv->cgroup) < 0) {
if (virCgroupNewIgnoreError())
goto done;
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index daea11dacb..8ac2dc92b5 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -687,6 +687,8 @@ virQEMUDriverConfigLoadProcessEntry(virQEMUDriverConfigPtr
cfg,
return -1;
if (virConfGetValueUInt(conf, "max_files", &cfg->maxFiles) < 0)
return -1;
+if (virConfGetValueUInt(conf, "max_threads_per_process",
&cfg->maxThreadsPerProc) < 0)
+return -1;
if (virConfGetValueType(conf, "max_core") == VIR_CONF_STRING) {
if (virConfGetValueString(conf, "max_core", &corestr) < 0)
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 983e74a3cf..48b8711cbd 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -171,6 +171,7 @@ struct _virQEMUDriverConfig {
unsigned int maxProcesses;
unsigned int maxFiles;
+unsigned int maxThreadsPerProc;
unsigned long long maxCore;
bool dumpGuestCore;
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
Re: [libvirt] [PATCH 0/3] tests: Include LDADDS in qemu_LDADDS
On 6/12/19 5:19 AM, Andrea Bolognani wrote: Finally got around to implement the suggestion I made in https://www.redhat.com/archives/libvir-list/2019-May/msg00894.html Andrea Bolognani (3): tests: Tweak cputest_LDADDS tests: Tweak vircapstest_LDADD tests: Include LDADDS in qemu_LDADDS tests/Makefile.am | 44 +--- 1 file changed, 25 insertions(+), 19 deletions(-) In addition to reviewing these changes, I also tested them in my LTO build setup. Other than the commit message nit in patch 1, looks good! Reviewed-by: Jim Fehlig Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] tests: Tweak cputest_LDADDS
On 6/12/19 5:19 AM, Andrea Bolognani wrote: We want have all test programs using qemu_LDADDS also use LDADDS, This part of the sentence seems awkward. How about "We want all test programs using qemu_LDADDS to also use LDADDS," ? and cputest is the only existing exception. We can't just replace GNULIB_LIBS with LDADDS though, even though the latter is a superset of the former, because that would result in a linking error due to including the same object twice: /usr/bin/ld: ../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141: multiple definition of `libvirt_object_new_semaphore'; ../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141: first defined here To work around this, we include both qemu_LDADDS and LDADDS when QEMU support is enabled, and just LDADDS otherwise. Signed-off-by: Andrea Bolognani --- tests/Makefile.am | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 6b17d99501..c34cfba34c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -962,11 +962,13 @@ interfacexml2xmltest_LDADD = $(LDADDS) cputest_SOURCES = \ cputest.c \ testutils.c testutils.h -cputest_LDADD = $(LDADDS) $(LIBXML_LIBS) +cputest_LDADD = $(LIBXML_LIBS) if WITH_QEMU cputest_SOURCES += testutilsqemu.c testutilsqemu.h -cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) $(GNULIB_LIBS) -endif WITH_QEMU +cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) $(LDADDS) +else ! WITH_QEMU +cputest_LDADD += $(LDADDS) +endif ! WITH_QEMU metadatatest_SOURCES = \ metadatatest.c \ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility
On Wed, 12 Jun 2019 09:14:39 +0200 Cornelia Huck wrote: > On Tue, 11 Jun 2019 14:28:22 -0600 > Alex Williamson wrote: > > > On Tue, 11 Jun 2019 21:45:08 +0200 > > Cornelia Huck wrote: > > > > > On Fri, 7 Jun 2019 18:06:30 +0200 > > > Halil Pasic wrote: > > > > > I guess for vfio-ccw one needs to make sure that the ccw device is bound > > > > to the vfio-ccw driver first, and only after that can one use > > > > create-mdev to create the mdev on top of the subchannel. > > > > > > > > So to make this work persistently (survive a reboot) one would need to > > > > take care of the subchannel getting bound to the right vfio_ccw driver > > > > before mdevctl is called. Right? > > > > > > > > BTW how does this concurrence situation between the drivers > > > > io_subchannel > > > > and vfio_ccw work? Especially if both are build in? > > > > > > If you have two drivers that match to the same device type, you'll > > > always have the issue that the driver that is first matched with the > > > device will bind to it and you have to do the unbind/rebind dance to > > > get it bound to the correct device driver. (I guess that this was the > > > basic motivation behind the ap bus default driver infrastructure, > > > right?) I think that in our case the io_subchannel driver will be > > > called first (alphabetical order and the fact that vfio-ccw will often > > > be a module). I'm not sure if it is within the scope of mdevctl to > > > ensure that the device is bound to the correct driver, or if it rather > > > should work with devices already bound to the correct driver only. > > > Maybe a separate udev-rules generator? > > > > Getting a device bound to a specific driver is exactly the domain of > > driverctl. Implement the sysfs interfaces driverctl uses and see if it > > works. Driverctl defaults to PCI and knows some extra things about > > PCI, but appears to be written to be generally bus agnostic. Thanks, > > > > Alex > @Alex: Thanks! I was not aware of driverctl. > Ok, looked at driverctl. Extending this one for non-PCI seems like a > reasonable path. However, we would also need to extend any non-PCI > device type we want to support with a driver_override attribute like > you did for PCI in 782a985d7af26db39e86070d28f987cad2 -- so this is > only for newer kernels. Adding that attribute for subchannels looks > feasible at a glance, but I have not tried to actually do it :) > > Halil, do you think that would make sense? Looks doable. Did not quite figure out the details yet, but it seems that for PCI driver_override has more benefits than for cio (compared to simple unbind/bind), as matching and probing seems to be more elaborate for PCI. The benefit I see are 1) the ability to exclude the device form driver binding, and 2) having the same mechanism and thus consistent experience for pci and cio. What we IMHO should not do is make driver_override the override the sch->st == id->type check. Regards, Halil > > [This might also help with the lcs vs. ctc confusion on a certain 3088 > cu model if this is added for ccw devices as well; but I'm not sure if > these are still out in the wild at all. Probably not worth the effort > for that.] -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility
On Tue, 11 Jun 2019 21:45:08 +0200 Cornelia Huck wrote: > On Fri, 7 Jun 2019 18:06:30 +0200 > Halil Pasic wrote: > > > On Fri, 24 May 2019 12:11:06 +0200 > > Cornelia Huck wrote: > > > > > On Thu, 23 May 2019 17:20:01 -0600 > > > Alex Williamson wrote: > > > > > > > Hi, > > > > > > > > [..] > > > > > > > > > > It would be really useful if s390 folks could help me understand > > > > whether it's possible to glean all the information necessary to > > > > recreate a ccw or ap mdev device from sysfs. I expect the file where > > > > we currently only store the mdev_type to evolve into something that > > > > includes more information to facilitate more complicated devices. For > > > > now I make no claims to maintaining compatibility of recorded mdev > > > > devices, it will absolutely change, but I didn't want to get bogged > > > > down in making sure I don't accidentally source a root kit hidden in an > > > > mdev config file. > > > > > > I played a bit with it on my LPAR, and it is at least not obviously > > > broken with vfio-ccw :) I don't have any ap devices to play with, > > > though. > > > > > > > Sorry for being late... > > > > I guess for vfio-ccw one needs to make sure that the ccw device is bound > > to the vfio-ccw driver first, and only after that can one use > > create-mdev to create the mdev on top of the subchannel. > > > > So to make this work persistently (survive a reboot) one would need to > > take care of the subchannel getting bound to the right vfio_ccw driver > > before mdevctl is called. Right? > > > > BTW how does this concurrence situation between the drivers io_subchannel > > and vfio_ccw work? Especially if both are build in? > > If you have two drivers that match to the same device type, you'll > always have the issue that the driver that is first matched with the > device will bind to it and you have to do the unbind/rebind dance to > get it bound to the correct device driver. (I guess that this was the > basic motivation behind the ap bus default driver infrastructure, > right?) Yes and no. The main idea behind the ap bus default driver infrastructure is to make devices 'return' to the right driver (family) even if the devices linux representation (kobj) gets destroyed and reconstructed (e.g. due to loss of connectivity). > I think that in our case the io_subchannel driver will be > called first (alphabetical order and the fact that vfio-ccw will often > be a module). Did some more digging vfio_ccw seems to be device_initcall, while io_subchannel subsys_initcall. I.e. we are safe there. > I'm not sure if it is within the scope of mdevctl to > ensure that the device is bound to the correct driver, or if it rather > should work with devices already bound to the correct driver only. > Maybe a separate udev-rules generator? > My point is, for persistent mdevctl should do it's magic after this mechanism kicked in. Otherwise mdevctl will fail to accomplish its purpose. I wonder if that is the case with driverctl. From what I say both have """ DefaultDependencies=no Before=basic.target """ in the @.service file... I'm just trying to figure out how the end-to end solution looks like. > There's also the question where that automatic configuration should > stop. Should cio_ignore handling be part of it as well? [That's a > non-generic interface, of course. Tooling within s390-tools, maybe?] > Isn't cio_ignore a /proc interface? I don't think mdevctl should be concerned with cio_ignore. Regards, Halil -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: domain: Log some useful data in qemuDomainStorageSourceAccessModify
Peter Krempa [2019-06-12, 01:53PM +0200]:
> Log the flags passed to the function in a exploded state so that it's
> easily visible what's happening to the image.
>
> Signed-off-by: Peter Krempa
> ---
> src/qemu/qemu_domain.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 2095191cde..d28cfa4f42 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -9339,6 +9339,9 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
> driver,
> int ret = -1;
> virErrorPtr orig_err = NULL;
> bool chain = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_CHAIN;
> +bool force_ro = flags &
> QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY;
> +bool force_rw = flags &
> QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE;
> +bool revoke = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_REVOKE;
> int rc;
> bool was_readonly = src->readonly;
> bool revoke_cgroup = false;
> @@ -9346,14 +9349,18 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
> driver,
> bool revoke_namespace = false;
> bool revoke_lockspace = false;
>
> -if (flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY)
> +VIR_DEBUG("VM: '%s', src: '%s', readonly: '%d, force_ro: '%d', force_rw:
> '%d', revoke: '%d', chain: '%d'",
Almost everywhere we use the syntax key=value when logging, so I'd
prefer this here as well.
--
IBM Systems
Linux on Z & Virtualization Development
--
IBM Deutschland Research & Development GmbH
Schönaicher Str. 220, 71032 Böblingen
Phone: +49 7031 16 1819
--
Vorsitzende des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: domain: Log some useful data in qemuDomainStorageSourceAccessModify
On Wed, Jun 12, 2019 at 01:53:39PM +0200, Peter Krempa wrote:
Log the flags passed to the function in a exploded state so that it's
s/a exploded/an exploded/
easily visible what's happening to the image.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_domain.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 2095191cde..d28cfa4f42 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -9339,6 +9339,9 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
driver,
int ret = -1;
virErrorPtr orig_err = NULL;
bool chain = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_CHAIN;
+bool force_ro = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY;
+bool force_rw = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE;
+bool revoke = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_REVOKE;
int rc;
bool was_readonly = src->readonly;
bool revoke_cgroup = false;
@@ -9346,14 +9349,18 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
driver,
bool revoke_namespace = false;
bool revoke_lockspace = false;
-if (flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY)
+VIR_DEBUG("VM: '%s', src: '%s', readonly: '%d, force_ro: '%d', force_rw: '%d',
revoke: '%d', chain: '%d'",
We usually use lowercase 'vm' in the logs. Also, the readonly attribue
has a mismatched attribute.
How about the more compact format we use elsewhere:
VIR_DEBUG("VM='%s', src='%s', readonly=%d force_ro=%d force_rw=%d revoke=%d
chain=%d".
+ vm->def->name, NULLSTR(src->path), src->readonly, force_ro,
+ force_rw, revoke, chain);
+
Reviewed-by: Ján Tomko
Jano
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: domain: Log some useful data in qemuDomainStorageSourceAccessModify
Log the flags passed to the function in a exploded state so that it's
easily visible what's happening to the image.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_domain.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 2095191cde..d28cfa4f42 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -9339,6 +9339,9 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
driver,
int ret = -1;
virErrorPtr orig_err = NULL;
bool chain = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_CHAIN;
+bool force_ro = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY;
+bool force_rw = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE;
+bool revoke = flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_REVOKE;
int rc;
bool was_readonly = src->readonly;
bool revoke_cgroup = false;
@@ -9346,14 +9349,18 @@ qemuDomainStorageSourceAccessModify(virQEMUDriverPtr
driver,
bool revoke_namespace = false;
bool revoke_lockspace = false;
-if (flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY)
+VIR_DEBUG("VM: '%s', src: '%s', readonly: '%d, force_ro: '%d', force_rw:
'%d', revoke: '%d', chain: '%d'",
+ vm->def->name, NULLSTR(src->path), src->readonly, force_ro,
+ force_rw, revoke, chain);
+
+if (force_ro)
src->readonly = true;
-if (flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE)
+if (force_rw)
src->readonly = false;
/* just tear down the disk access */
-if (flags & QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_REVOKE) {
+if (revoke) {
virErrorPreserveLast(&orig_err);
revoke_cgroup = true;
revoke_label = true;
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] tests: Tweak vircapstest_LDADD
We optionally include QEMU and LXC support in this test and depending on which is enabled (if either is enabled at all) we need to link in different objects. Right now we implicitly depend on the fact that qemu_LDADDS is empty when QEMU is not enabled to get the correct set of objects, but it's better to be explicit about it. Signed-off-by: Andrea Bolognani --- tests/Makefile.am | 4 1 file changed, 4 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index c34cfba34c..f9dbf9a0f6 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1029,7 +1029,11 @@ endif WITH_LXC if WITH_QEMU vircapstest_SOURCES += testutilsqemu.c testutilsqemu.h endif WITH_QEMU +if WITH_QEMU vircapstest_LDADD = $(qemu_LDADDS) $(LDADDS) +else ! WITH_QEMU +vircapstest_LDADD = $(LDADDS) +endif ! WITH_QEMU domaincapsmock_la_SOURCES = domaincapsmock.c domaincapsmock_la_LDFLAGS = $(MOCKLIBS_LDFLAGS) -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] tests: Include LDADDS in qemu_LDADDS
Finally got around to implement the suggestion I made in https://www.redhat.com/archives/libvir-list/2019-May/msg00894.html Andrea Bolognani (3): tests: Tweak cputest_LDADDS tests: Tweak vircapstest_LDADD tests: Include LDADDS in qemu_LDADDS tests/Makefile.am | 44 +--- 1 file changed, 25 insertions(+), 19 deletions(-) -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] tests: Include LDADDS in qemu_LDADDS
At this point, all test programs that use qemu_LDADDS also use LDADDS, so we can remove a bunch of repetition by simply including the latter in the former. Signed-off-by: Andrea Bolognani --- tests/Makefile.am | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index f9dbf9a0f6..5ba529124a 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -554,10 +554,11 @@ endif WITH_STORAGE if WITH_DTRACE_PROBES qemu_LDADDS += ../src/libvirt_qemu_probes.lo endif WITH_DTRACE_PROBES +qemu_LDADDS += $(LDADDS) libqemutestdriver_la_SOURCES = libqemutestdriver_la_LDFLAGS = $(DRIVERLIB_LDFLAGS) -libqemutestdriver_la_LIBADD = $(qemu_LDADDS) $(LDADDS) +libqemutestdriver_la_LIBADD = $(qemu_LDADDS) qemucpumock_la_SOURCES = \ qemucpumock.c testutilshostcpus.h @@ -580,7 +581,7 @@ qemuxml2argvmock_la_LIBADD = $(MOCKLIBS_LIBS) qemuxml2xmltest_SOURCES = \ qemuxml2xmltest.c testutilsqemu.c testutilsqemu.h \ testutils.c testutils.h -qemuxml2xmltest_LDADD = $(qemu_LDADDS) $(LDADDS) +qemuxml2xmltest_LDADD = $(qemu_LDADDS) qemuargv2xmltest_SOURCES = \ qemuargv2xmltest.c testutilsqemu.c testutilsqemu.h \ @@ -594,7 +595,7 @@ qemumonitorjsontest_SOURCES = \ testutilsqemu.c testutilsqemu.h \ $(NULL) qemumonitorjsontest_LDADD = libqemumonitortestutils.la \ - $(qemu_LDADDS) $(LDADDS) + $(qemu_LDADDS) qemucapabilitiestest_SOURCES = \ qemucapabilitiestest.c \ @@ -602,7 +603,7 @@ qemucapabilitiestest_SOURCES = \ testutilsqemu.c testutilsqemu.h \ $(NULL) qemucapabilitiestest_LDADD = libqemumonitortestutils.la \ - $(qemu_LDADDS) $(LDADDS) + $(qemu_LDADDS) qemucapsprobe_SOURCES = \ qemucapsprobe.c @@ -620,14 +621,14 @@ qemucommandutiltest_SOURCES = \ testutilsqemu.c testutilsqemu.h \ $(NULL) qemucommandutiltest_LDADD = libqemumonitortestutils.la \ - $(qemu_LDADDS) $(LDADDS) + $(qemu_LDADDS) qemucaps2xmltest_SOURCES = \ qemucaps2xmltest.c \ testutils.c testutils.h \ testutilsqemu.c testutilsqemu.h \ $(NULL) -qemucaps2xmltest_LDADD = $(qemu_LDADDS) $(LDADDS) +qemucaps2xmltest_LDADD = $(qemu_LDADDS) qemucaps2xmlmock_la_SOURCES = \ qemucaps2xmlmock.c @@ -639,14 +640,14 @@ qemuagenttest_SOURCES = \ testutils.c testutils.h \ testutilsqemu.c testutilsqemu.h \ $(NULL) -qemuagenttest_LDADD = libqemumonitortestutils.la $(qemu_LDADDS) $(LDADDS) +qemuagenttest_LDADD = libqemumonitortestutils.la $(qemu_LDADDS) qemuhotplugtest_SOURCES = \ qemuhotplugtest.c \ testutils.c testutils.h \ testutilsqemu.c testutilsqemu.h \ $(NULL) -qemuhotplugtest_LDADD = libqemumonitortestutils.la $(qemu_LDADDS) $(LDADDS) +qemuhotplugtest_LDADD = libqemumonitortestutils.la $(qemu_LDADDS) qemublocktest_SOURCES = \ qemublocktest.c \ @@ -658,19 +659,18 @@ qemublocktest_LDADD = \ ../src/libvirt_conf.la \ ../src/libvirt_util.la \ $(qemu_LDADDS) \ - $(LDADDS) \ $(NULL) domainsnapshotxml2xmltest_SOURCES = \ domainsnapshotxml2xmltest.c testutilsqemu.c testutilsqemu.h \ testutils.c testutils.h -domainsnapshotxml2xmltest_LDADD = $(qemu_LDADDS) $(LDADDS) +domainsnapshotxml2xmltest_LDADD = $(qemu_LDADDS) qemumemlocktest_SOURCES = \ qemumemlocktest.c \ testutilsqemu.c testutilsqemu.h \ testutils.c testutils.h -qemumemlocktest_LDADD = $(qemu_LDADDS) $(LDADDS) +qemumemlocktest_LDADD = $(qemu_LDADDS) qemumigparamstest_SOURCES = \ qemumigparamstest.c \ @@ -678,21 +678,21 @@ qemumigparamstest_SOURCES = \ testutilsqemu.c testutilsqemu.h \ $(NULL) qemumigparamstest_LDADD = libqemumonitortestutils.la \ - $(qemu_LDADDS) $(LDADDS) + $(qemu_LDADDS) qemusecuritytest_SOURCES = \ qemusecuritytest.c qemusecuritytest.h \ qemusecuritymock.c \ testutils.h testutils.c \ testutilsqemu.h testutilsqemu.c -qemusecuritytest_LDADD = $(qemu_LDADDS) $(LDADDS) +qemusecuritytest_LDADD = $(qemu_LDADDS) qemufirmwaretest_SOURCES = \ qemufirmwaretest.c \ testutils.h testutils.c \ virfilewrapper.c virfilewrapper.h \ $(NULL) -qemufirmwaretest_LDADD = $(qemu_LDADDS) $(LDADDS) +qemufirmwaretest_LDADD = $(qemu_LDADDS) else ! WITH_QEMU EXTRA_DIST += qemuxml2argvtest.c qemuxml2xmltest.c qemuargv2xmltest.c \ @@ -965,7 +965,7 @@ cputest_SOURCES = \ cputest_LDADD = $(LIBXML_LIBS) if WITH_QEMU cputest_SOURCES += testutilsqemu.c testutilsqemu.h -cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) $(LDADDS) +cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) else ! WITH_QEMU cputest_LDADD += $(LDADDS) endif ! WITH_QEMU @@ -1030,7 +1030,7 @@ if WITH_QEMU vircapstest_SOURCES += testutilsqemu.c testutilsqemu.h endif WITH_QEMU if WITH_QEMU -vircapstest_LDADD = $(qemu
Re: [libvirt] [PATCH] build: fix linking libqemutestdriver with LTO enabled
On Tue, 2019-06-04 at 09:33 +0200, Andrea Bolognani wrote: > I have something almost reasonable in a local branch, I'll polish it > up in the next few days and then post it. Done :) https://www.redhat.com/archives/libvir-list/2019-June/msg00339.html -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] tests: Tweak cputest_LDADDS
We want have all test programs using qemu_LDADDS also use LDADDS, and cputest is the only existing exception. We can't just replace GNULIB_LIBS with LDADDS though, even though the latter is a superset of the former, because that would result in a linking error due to including the same object twice: /usr/bin/ld: ../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141: multiple definition of `libvirt_object_new_semaphore'; ../src/libvirt_probes.o:.../src/libvirt_probes.o.dtrace-temp.c:141: first defined here To work around this, we include both qemu_LDADDS and LDADDS when QEMU support is enabled, and just LDADDS otherwise. Signed-off-by: Andrea Bolognani --- tests/Makefile.am | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 6b17d99501..c34cfba34c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -962,11 +962,13 @@ interfacexml2xmltest_LDADD = $(LDADDS) cputest_SOURCES = \ cputest.c \ testutils.c testutils.h -cputest_LDADD = $(LDADDS) $(LIBXML_LIBS) +cputest_LDADD = $(LIBXML_LIBS) if WITH_QEMU cputest_SOURCES += testutilsqemu.c testutilsqemu.h -cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) $(GNULIB_LIBS) -endif WITH_QEMU +cputest_LDADD += libqemumonitortestutils.la $(qemu_LDADDS) $(LDADDS) +else ! WITH_QEMU +cputest_LDADD += $(LDADDS) +endif ! WITH_QEMU metadatatest_SOURCES = \ metadatatest.c \ -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] test_driver: implement virDomainGetLaunchSecurityInfo
On Tue, Jun 11, 2019 at 01:07:26PM +0200, Ilias Stamatis wrote:
> Since this is the test driver and this is tied to AMD CPUs at the
> moment, we can pretend that the domain doesn't have launch security and
> always return 0 parameters.
I'd reword this in a bit different way:
"Since the behaviour of launch security is heavily dependent on 3rd party
vendors (e.g. AMD SEV) where the data returned can be essentially anything,
the most reasonable approach here in the test driver is not to try return any
data."
Reviewed-by: Erik Skultety
>
> Signed-off-by: Ilias Stamatis
> ---
> src/test/test_driver.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/src/test/test_driver.c b/src/test/test_driver.c
> index 1aa79ce898..213f17808b 100644
> --- a/src/test/test_driver.c
> +++ b/src/test/test_driver.c
> @@ -2284,6 +2284,18 @@ testDomainGetOSType(virDomainPtr dom ATTRIBUTE_UNUSED)
> }
>
>
> +static int
> +testDomainGetLaunchSecurityInfo(virDomainPtr domain ATTRIBUTE_UNUSED,
> +virTypedParameterPtr *params
> ATTRIBUTE_UNUSED,
> +int *nparams,
> +unsigned int flags)
> +{
> +virCheckFlags(0, -1);
I'll put an extra newline here.
> +*nparams = 0;
> +return 0;
> +}
> +
> +
> static unsigned long long
> testDomainGetMaxMemory(virDomainPtr domain)
> {
> @@ -7011,6 +7023,7 @@ static virHypervisorDriver testHypervisorDriver = {
> .domainDestroy = testDomainDestroy, /* 0.1.1 */
> .domainDestroyFlags = testDomainDestroyFlags, /* 4.2.0 */
> .domainGetOSType = testDomainGetOSType, /* 0.1.9 */
> +.domainGetLaunchSecurityInfo = testDomainGetLaunchSecurityInfo, /* 5.5.0
> */
> .domainGetMaxMemory = testDomainGetMaxMemory, /* 0.1.4 */
> .domainSetMaxMemory = testDomainSetMaxMemory, /* 0.1.1 */
> .domainSetMemory = testDomainSetMemory, /* 0.1.4 */
> --
> 2.21.0
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2]daemon: Fix a crash during virNetlinkEventServiceStopAll
The steps to reproduce: 1. create a xml file including the following configuration. function='0x0' /> function='0x0'/> 2. ensure you systemd has supported core dump function 3. create and start vm with virsh command sysctl -w kernel.core_pattern=/core.%u.%e.%p brctl addbr ctrlbr0 virsh create vm.xml 4. when the vm has started up completely, reboot the host with the following command reboot -d Note, you must set one real Ethernet port(eth0,or eth1) to a direct mode in xml file. On 2019/6/12 15:18, Liu Haitao wrote: When reboot the host, a core dump file would be generated. The call traces are: Note.In this case, the main thread is thread 5. (gdb) thread 5 [Switching to thread 5 (LWP 4142)] (gdb) bt 0 0x7f00a6838273 in futex_wait_cancelable (private=, expected=0, futex_word=0x7f004c0125c0) at /usr/src/debug/glibc/2.24-r0/git/sysdeps/unix/sysv/linux/futex-internal.h:88 1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7f004c012540, cond=0x7f004c012598) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_cond_wait.c:502 2 __pthread_cond_wait (cond=0x7f004c012598, mutex=0x7f004c012540) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_cond_wait.c:655 3 0x7f00aa467246 in virCondWait (c=, m=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:154 4 0x7f00aa467eb0 in virThreadPoolFree (pool=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthreadpool.c:286 5 0x7f0074349f9d in qemuStateCleanup () at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:1036 6 0x7f00aa5e9486 in virStateCleanup () at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/libvirt.c:682 7 0x55a687ab86a4 in main (argc=, argv=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/remote/remote_daemon.c:1473 (gdb) thread 1 [Switching to thread 1 (LWP 4403)] (gdb) bt 0 __GI___pthread_mutex_lock (mutex=mutex@entry=0x0) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_mutex_lock.c:67 1 0x7f00aa467165 in virMutexLock (m=m@entry=0x0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:89 2 0x7f00aa43c0f9 in virNetlinkEventServerLock (driver=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetlink.c:799 3 virNetlinkEventRemoveClient (watch=watch@entry=0, macaddr=macaddr@entry=0x7f0088014944, protocol=protocol@entry=0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetlink.c:1197 4 0x7f00aa4341df in virNetDevMacVLanDeleteWithVPortProfile ( ifname=, macaddr=macaddr@entry=0x7f0088014944, linkdev=0x7f0088014920 "eth1", mode=mode@entry=1, virtPortProfile=virtPortProfile@entry=0x0, stateDir=stateDir@entry=0x7f004c12fa90 "/var/run/libvirt/qemu") at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetdevmacvlan.c:1112 5 0x7f0074312251 in qemuProcessStop (driver=driver@entry=0x7f004c0ecef0, vm=vm@entry=0x7f0088000b00, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN, asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_process.c:7291 6 0x7f007437a5ea in processMonitorEOFEvent (vm=0x7f0088000b00, driver=0x7f004c0ecef0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:4756 7 qemuProcessEventHandler (data=0x55a687d6df10, opaque=0x7f004c0ecef0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:4859 8 0x7f00aa467c5b in virThreadPoolWorker ( opaque=opaque@entry=0x55a687d6c110) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthreadpool.c:163 9 0x7f00aa466fe8 in virThreadHelper (data=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:206 10 0x7f00a68323f4 in start_thread (arg=0x7f00699df700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 11 0x7f00a616e10f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 1. The execution flow of main thread (Thread 5 LWP 4142): main() -->virNetDaemonRun() -->virNetDaemonClose(dmn) //cleanup -->virNetlinkEventServiceStopAll() -->virStateCleanup() -->qemuStateCleanup() -->virThreadPoolFree() -->__pthread_cond_wait() virNetDaemonRun() -->virEventRunDefaultImpl -->virEventPollRunOnce -->virEventPollDispatchHandles -->qemuMonitorIO -->qemuProcessHandleMonitorEOF -->processEvent->eventType = QEMU_PROCESS_EVENT_MONITOR_EOF -->virThreadPoolSendJob() After typing reboot command on the host, the main thread would send an event message to another thread. Here it would let thread 1 to handle the shutdown of qemu process. But it could not be executed immediately. virNetlinkEventServiceStopAll()
[libvirt] [PATCH v2]daemon: Fix a crash during virNetlinkEventServiceStopAll
When reboot the host, a core dump file would be generated. The call traces are: Note.In this case, the main thread is thread 5. (gdb) thread 5 [Switching to thread 5 (LWP 4142)] (gdb) bt 0 0x7f00a6838273 in futex_wait_cancelable (private=, expected=0, futex_word=0x7f004c0125c0) at /usr/src/debug/glibc/2.24-r0/git/sysdeps/unix/sysv/linux/futex-internal.h:88 1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7f004c012540, cond=0x7f004c012598) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_cond_wait.c:502 2 __pthread_cond_wait (cond=0x7f004c012598, mutex=0x7f004c012540) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_cond_wait.c:655 3 0x7f00aa467246 in virCondWait (c=, m=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:154 4 0x7f00aa467eb0 in virThreadPoolFree (pool=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthreadpool.c:286 5 0x7f0074349f9d in qemuStateCleanup () at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:1036 6 0x7f00aa5e9486 in virStateCleanup () at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/libvirt.c:682 7 0x55a687ab86a4 in main (argc=, argv=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/remote/remote_daemon.c:1473 (gdb) thread 1 [Switching to thread 1 (LWP 4403)] (gdb) bt 0 __GI___pthread_mutex_lock (mutex=mutex@entry=0x0) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_mutex_lock.c:67 1 0x7f00aa467165 in virMutexLock (m=m@entry=0x0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:89 2 0x7f00aa43c0f9 in virNetlinkEventServerLock (driver=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetlink.c:799 3 virNetlinkEventRemoveClient (watch=watch@entry=0, macaddr=macaddr@entry=0x7f0088014944, protocol=protocol@entry=0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetlink.c:1197 4 0x7f00aa4341df in virNetDevMacVLanDeleteWithVPortProfile ( ifname=, macaddr=macaddr@entry=0x7f0088014944, linkdev=0x7f0088014920 "eth1", mode=mode@entry=1, virtPortProfile=virtPortProfile@entry=0x0, stateDir=stateDir@entry=0x7f004c12fa90 "/var/run/libvirt/qemu") at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virnetdevmacvlan.c:1112 5 0x7f0074312251 in qemuProcessStop (driver=driver@entry=0x7f004c0ecef0, vm=vm@entry=0x7f0088000b00, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN, asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_process.c:7291 6 0x7f007437a5ea in processMonitorEOFEvent (vm=0x7f0088000b00, driver=0x7f004c0ecef0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:4756 7 qemuProcessEventHandler (data=0x55a687d6df10, opaque=0x7f004c0ecef0) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/qemu/qemu_driver.c:4859 8 0x7f00aa467c5b in virThreadPoolWorker ( opaque=opaque@entry=0x55a687d6c110) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthreadpool.c:163 9 0x7f00aa466fe8 in virThreadHelper (data=) at /usr/src/debug/libvirt/5.3.0-r0/libvirt-5.3.0/src/util/virthread.c:206 10 0x7f00a68323f4 in start_thread (arg=0x7f00699df700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 11 0x7f00a616e10f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 1. The execution flow of main thread (Thread 5 LWP 4142): main() -->virNetDaemonRun() -->virNetDaemonClose(dmn) //cleanup -->virNetlinkEventServiceStopAll() -->virStateCleanup() -->qemuStateCleanup() -->virThreadPoolFree() -->__pthread_cond_wait() virNetDaemonRun() -->virEventRunDefaultImpl -->virEventPollRunOnce -->virEventPollDispatchHandles -->qemuMonitorIO -->qemuProcessHandleMonitorEOF -->processEvent->eventType = QEMU_PROCESS_EVENT_MONITOR_EOF -->virThreadPoolSendJob() After typing reboot command on the host, the main thread would send an event message to another thread. Here it would let thread 1 to handle the shutdown of qemu process. But it could not be executed immediately. virNetlinkEventServiceStopAll() --> virNetlinkEventServiceStop() --> server[protocol] = NULL; // set server to null IN virNetlinkEventServiceStopAll(), some variables related to network are freed, like (static virNetlinkEventSrvPrivatePtr server). virStateCleanup() -->qemuStateCleanup() -->virThreadPoolFree() -->__pthread_cond_wait() In virThreadPoolFree() it will wait other thread to end up. 2. The execution flow of thread 5 (LWP 4403): qemuProcessStop() -->virNetDevMacVLanDeleteWithVPortProfile() -->virNetlinkEventRemoveClient() --> srv = server[protocol] Although the main thread had sent the message
[libvirt] [PATCH] tests: qemumonitorjson: Replace use of virReportError
Use VIR_TEST_VERBOSE instead. This fixes the following syntax check
problem:
tests/qemumonitorjsontest.c:1409:virReportError(VIR_ERR_INTERNAL_ERROR,
"arr should have been cleared");
Signed-off-by: Peter Krempa
---
Pushed under the build-breaker rule.
tests/qemumonitorjsontest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c
index 68b115fa89..e087d1c256 100644
--- a/tests/qemumonitorjsontest.c
+++ b/tests/qemumonitorjsontest.c
@@ -1406,7 +1406,7 @@ testQemuMonitorJSONqemuMonitorJSONMergeBitmaps(const void
*opaque)
return -1;
if (arr) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "arr should have been cleared");
+VIR_TEST_VERBOSE("arr should have been cleared");
return -1;
}
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility
On Tue, 11 Jun 2019 14:28:22 -0600 Alex Williamson wrote: > On Tue, 11 Jun 2019 21:45:08 +0200 > Cornelia Huck wrote: > > > On Fri, 7 Jun 2019 18:06:30 +0200 > > Halil Pasic wrote: > > > I guess for vfio-ccw one needs to make sure that the ccw device is bound > > > to the vfio-ccw driver first, and only after that can one use > > > create-mdev to create the mdev on top of the subchannel. > > > > > > So to make this work persistently (survive a reboot) one would need to > > > take care of the subchannel getting bound to the right vfio_ccw driver > > > before mdevctl is called. Right? > > > > > > BTW how does this concurrence situation between the drivers io_subchannel > > > and vfio_ccw work? Especially if both are build in? > > > > If you have two drivers that match to the same device type, you'll > > always have the issue that the driver that is first matched with the > > device will bind to it and you have to do the unbind/rebind dance to > > get it bound to the correct device driver. (I guess that this was the > > basic motivation behind the ap bus default driver infrastructure, > > right?) I think that in our case the io_subchannel driver will be > > called first (alphabetical order and the fact that vfio-ccw will often > > be a module). I'm not sure if it is within the scope of mdevctl to > > ensure that the device is bound to the correct driver, or if it rather > > should work with devices already bound to the correct driver only. > > Maybe a separate udev-rules generator? > > Getting a device bound to a specific driver is exactly the domain of > driverctl. Implement the sysfs interfaces driverctl uses and see if it > works. Driverctl defaults to PCI and knows some extra things about > PCI, but appears to be written to be generally bus agnostic. Thanks, > > Alex Ok, looked at driverctl. Extending this one for non-PCI seems like a reasonable path. However, we would also need to extend any non-PCI device type we want to support with a driver_override attribute like you did for PCI in 782a985d7af26db39e86070d28f987cad2 -- so this is only for newer kernels. Adding that attribute for subchannels looks feasible at a glance, but I have not tried to actually do it :) Halil, do you think that would make sense? [This might also help with the lcs vs. ctc confusion on a certain 3088 cu model if this is added for ccw devices as well; but I'm not sure if these are still out in the wild at all. Probably not worth the effort for that.] -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
