[libvirt] Report of tsan first testing with libvirt(d)
by Daniel Veillard
Tsan is a heavilly reworked version of helgrind the
data race detector based on Valgrind (at least for linux)
It is developped by Google and described/available there:
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer
as libvirt code is highly threaded I though that we should try
testing it. Helgrind used to not be very practicable but Google
suggest they significantly speed up the process and decreased the
number of false positive.
I tried to build it from source, but it failed in some ways
by not finding the i386/686 libraries build when run on my x86_64,
could be related to differences in distribution, they use only
Ubuntu, and I tested on Fedora 16, I didn't tried to really solve the
issue at that point.
One of the problem of such a configuration is that the program doesn't
have what could be specific Fedora exception lists for valgrind.
So I grabbed the prebuilt version tsan-r4363-amd64-linux-self-contained.sh
(it's a self extracting binary in shell script) from
http://build.chromium.org/p/client.tsan/binaries/
renamid tsan.sh and installed it in my path, works fine...
I did a first test run with libxml2 code I know very well and
the result were good, i.e. it pointed out a data race I know about
and raised another one about some global data initialization,
so fairly positive from my POV.
Then I instrumented libvirt daemon for 0.9.12 release, launched it
as root from command line as a tsan argument:
/tmp/tsan.sh --trace-children=no /usr/sbin/libvirtd
and then played with virt-manager to exercise it a bit.
At first I tried to use --log-file=tsan.log option to collect
the logs but the logfile got corrupted so the following is
just cut and paste from the output
One of the ouput raised frequently is:
----------------------------------------------------------------------
==5838== WARNING: Possible data race during write of size 4 at 0x34723B3BD0: {{{
==5838== T1 (L{L17, L125}):
==5838== #0 ptmalloc_unlock_all2 /lib64/libc-2.14.90.so
==5838== #1 fork /lib64/libc-2.14.90.so
==5838== #2 virFork /usr/src/debug/libvirt-0.9.12/src/util/command.c:268
==5838== #3 virExecWithHook.constprop.5 /usr/src/debug/libvirt-0.9.12/src/util/command.c:489
==5838== #4 virCommandRunAsync /usr/src/debug/libvirt-0.9.12/src/util/command.c:2177
==5838== #5 virCommandRun /usr/src/debug/libvirt-0.9.12/src/util/command.c:1970
==5838== #6 qemuCapsExtractVersionInfo /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1379
==5838== #7 qemuCapsExtractVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1568
==5838== #8 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1320
==5838== #9 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640
==5838== #10 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862
==5838== #11 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416
==5838== Concurrent read(s) happened at (OR AFTER) these points:
==5838== T11 (L{}):
==5838== #0 arena_thread_freeres /lib64/libc-2.14.90.so
==5838== #1 __libc_thread_freeres /lib64/libc-2.14.90.so
==5838== #2 start_thread /lib64/libpthread-2.14.90.so
==5838== Address 0x34723B3BD0 is 0 bytes inside data symbol "list_lock"
==5838== Locks involved in this report (reporting last lock sites): {L17, L125}
==5838== L17 (0x5339B00)
==5838== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935
==5838== #1 virFork /usr/src/debug/libvirt-0.9.12/src/util/command.c:266
==5838== #2 virExecWithHook.constprop.5 /usr/src/debug/libvirt-0.9.12/src/util/command.c:489
==5838== #3 virCommandRunAsync /usr/src/debug/libvirt-0.9.12/src/util/command.c:2177
==5838== #4 virCommandRun /usr/src/debug/libvirt-0.9.12/src/util/command.c:1970
==5838== #5 qemuCapsExtractVersionInfo /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1379
==5838== #6 qemuCapsExtractVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_capabilities.c:1568
==5838== #7 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1320
==5838== #8 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640
==5838== #9 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862
==5838== #10 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416
==5838== #11 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5838== L125 (0x4C0A0A00)
==5838== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935
==5838== #1 qemudGetVersion /usr/src/debug/libvirt-0.9.12/src/qemu/qemu_driver.c:1319
==5838== #2 virConnectGetVersion /usr/src/debug/libvirt-0.9.12/src/libvirt.c:1640
==5838== #3 remoteDispatchGetVersionHelper /usr/src/debug/libvirt-0.9.12/daemon/remote_dispatch.h:6862
==5838== #4 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416
==5838== #5 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5838== #6 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144
==5838== #7 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161
==5838== Race verifier data: 0x347207CF98,0x347215D6BB
==5838== }}}
I don't know what "Race verifier data" means but it seems that we do
*pid = fork(); in the main thread and that another thread is accessing
without synchronization. The probram properly report that 2 locks are
held at that point, the virLogLock() and qemuDriverLock() and give full
stack trace on where those locks were taken. That's convenient but
I could not really spot where the second thread did the access, I suspect
that's somehow related to libpthread considering the minimal stack trace
of the second thread T11 ...
Unfortunately, it seems that each time we fork we hit one or two
issue like that (which could be false positive), and tend to fill logs
relatively fast :-\
I however found out a couple of issues not related to libpthread:
==5733== WARNING: Possible data race during write of size 1 at 0x34723B6B14: {{{
==5733== T5 (L{}):
==5733== #0 Replace_memcpy /mnt/data/build/slave/full_linux_build/build/tsan/ts_replace.h:113
==5733== #1 __GI_memcpy /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:2359
==5733== #2 xdrmem_getbytes /lib64/libc-2.14.90.so
==5733== #3 xdr_string /lib64/libc-2.14.90.so
==5733== #4 xdr_remote_nonnull_string /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:31
==5733== #5 xdr_remote_nonnull_domain /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:58
==5733== #6 xdr_remote_domain_get_info_args /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:1390
==5733== #7 virNetMessageDecodePayload /usr/src/debug/libvirt-0.9.12/src/rpc/virnetmessage.c:382
==5733== #8 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:403
==5733== #9 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5733== #10 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144
==5733== #11 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161
==5733== Concurrent write(s) happened at (OR AFTER) these points:
==5733== T2 (L{}):
==5733== #0 xdrmem_getbytes /lib64/libc-2.14.90.so
==5733== #1 xdr_string /lib64/libc-2.14.90.so
==5733== #2 xdr_remote_nonnull_string /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:31
==5733== #3 xdr_remote_nonnull_domain /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:58
==5733== #4 xdr_remote_domain_get_xml_desc_args /usr/src/debug/libvirt-0.9.12/daemon/../src/remote/remote_protocol.c:1532
==5733== #5 virNetMessageDecodePayload /usr/src/debug/libvirt-0.9.12/src/rpc/virnetmessage.c:382
==5733== #6 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:403
==5733== #7 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5733== #8 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144
==5733== #9 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161
==5733== Address 0x34723B6B14 is 0 bytes inside data symbol "crud.6424"
==5733== Race verifier data: 0x4A091CE,0x347212579D
==5733== }}}
that one could potentially be nasty, it seems that 2 threads decoding
rpc payload in parallel hit an unsynchronized write access in
the xdr routine for xdr_remote_nonnull_string() . I didn't had the
debuginfo for glibc installed when I ran it so I don't have the
exact informations at the top of the stacks
The other one raised is actually something I had initially found
with the first run on libxml2 so it's relatively consistent:
==5733== WARNING: Possible data race during read of size 4 at 0x34723B10B4: {{{
==5733== T1 (L{L173}):
==5733== #0 random_r /lib64/libc-2.14.90.so
==5733== #1 random /lib64/libc-2.14.90.so
==5733== #2 rand /lib64/libc-2.14.90.so
==5733== #3 xmlDictCreate /usr/src/debug/libxml2-2.8.0/dict.c:491
==5733== #4 xmlInitParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1620
==5733== #5 xmlNewParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1874
==5733== #6 xmlCreateURLParserCtxt /usr/src/debug/libxml2-2.8.0/parser.c:13546
==5733== #7 xmlReadFile /usr/src/debug/libxml2-2.8.0/parser.c:14713
==5733== #8 xmlRelaxNGParse /usr/src/debug/libxml2-2.8.0/relaxng.c:7480
==5733== #9 (no symbols) /usr/lib64/libnetcf.so.1.4.0
==5733== #10 ncf_init /usr/lib64/libnetcf.so.1.4.0
==5733== #11 interfaceOpenInterface /usr/src/debug/libvirt-0.9.12/src/interface/netcf_driver.c:144
==5733== Concurrent write(s) happened at (OR AFTER) these points:
==5733== T10 (L{L156}):
==5733== #0 random_r /lib64/libc-2.14.90.so
==5733== #1 random /lib64/libc-2.14.90.so
==5733== #2 rand /lib64/libc-2.14.90.so
==5733== #3 xmlHashCreate /usr/src/debug/libxml2-2.8.0/hash.c:193
==5733== #4 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:4125
==5733== #5 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6380
==5733== #6 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523
==5733== #7 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6319
==5733== #8 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6520
==5733== #9 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523
==5733== Address 0x34723B10B4 is 20 bytes inside data symbol "randtbl"
==5733== Locks involved in this report (reporting last lock sites): {L156, L173}
==5733== L156 (0x402E790)
==5733== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935
==5733== #1 remoteDispatchOpenHelper /usr/src/debug/libvirt-0.9.12/daemon/remote.c:683
==5733== #2 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416
==5733== #3 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5733== #4 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144
==5733== #5 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161
==5733== L173 (0x402F420)
==5733== #0 pthread_mutex_lock /mnt/data/build/slave/full_linux_build/build/tsan/ts_valgrind_intercepts.c:935
==5733== #1 remoteDispatchOpenHelper /usr/src/debug/libvirt-0.9.12/daemon/remote.c:683
==5733== #2 virNetServerProgramDispatch /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserverprogram.c:416
==5733== #3 virNetServerHandleJob /usr/src/debug/libvirt-0.9.12/src/rpc/virnetserver.c:161
==5733== #4 virThreadPoolWorker /usr/src/debug/libvirt-0.9.12/src/util/threadpool.c:144
==5733== #5 virThreadHelper /usr/src/debug/libvirt-0.9.12/src/util/threads-pthread.c:161
==5733== Race verifier data: 0x347203A572,0x347203A565
==5733== }}}
I didn't know that netcf was doing Relax-NG validation on-the-fly :)
and hit another in libxml2 though libvirt/netcf/libxslt/libxml2
call:
==5733== WARNING: Possible data race during read of size 4 at 0x34723B10B4: {{{
==5733== T1 (L{L173}):
==5733== #0 random_r /lib64/libc-2.14.90.so
==5733== #1 random /lib64/libc-2.14.90.so
==5733== #2 rand /lib64/libc-2.14.90.so
==5733== #3 xmlDictCreate /usr/src/debug/libxml2-2.8.0/dict.c:491
==5733== #4 xmlInitParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1620
==5733== #5 xmlNewParserCtxt /usr/src/debug/libxml2-2.8.0/parserInternals.c:1874
==5733== #6 xmlCreateURLParserCtxt /usr/src/debug/libxml2-2.8.0/parser.c:13546
==5733== #7 xmlReadFile /usr/src/debug/libxml2-2.8.0/parser.c:14713
==5733== #8 xmlRelaxNGParse /usr/src/debug/libxml2-2.8.0/relaxng.c:7480
==5733== #9 (no symbols) /usr/lib64/libnetcf.so.1.4.0
==5733== #10 ncf_init /usr/lib64/libnetcf.so.1.4.0
==5733== #11 interfaceOpenInterface /usr/src/debug/libvirt-0.9.12/src/interface/netcf_driver.c:144
==5733== Concurrent write(s) happened at (OR AFTER) these points:
==5733== T10 (L{L156}):
==5733== #0 random_r /lib64/libc-2.14.90.so
==5733== #1 random /lib64/libc-2.14.90.so
==5733== #2 rand /lib64/libc-2.14.90.so
==5733== #3 xmlHashCreate /usr/src/debug/libxml2-2.8.0/hash.c:193
==5733== #4 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:4125
==5733== #5 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6380
==5733== #6 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523
==5733== #7 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6319
==5733== #8 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6520
==5733== #9 xmlRelaxNGCheckRules /usr/src/debug/libxml2-2.8.0/relaxng.c:6523
==5733== Address 0x34723B10B4 is 20 bytes inside data symbol "randtbl"
==5733== Locks involved in this report (reporting last lock sites): {L156, L173}
Looks like another libxml2 bug calling rand, I should use rand_r() instead
if available.
I also ran virsh itself under tsan for a few functions, but that didn't
raise any issue.
So except for the parallel xdr_remote_nonnull_string() issue
I don't think there is anything I can report at this point for libvirt
code itself.
The slowdown of tsan is acceptable, virt-manager is a clearly a bit
less responsive when connecting of doing libvirt operations but it
is really usable, and that's IMHO the main point of my testing,
it's not hard (though it would be better if packaged for Fedora)
and the results are interesting but a bit heavy since the same issue
can pop-up all the time like for fork().
I guess it would be interesting to try out qemu-kvm with it though
it may turn unbearably slow, but it's worth testing !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
13 years, 1 month
[libvirt] [PATCH 1/1] Assign spapr-vio address value to VIO devices without hardcode
by Li Zhang
Hardcode address will cause conflicts when there are a lot of VIO
devices.
This patch is to remove the harcode of the address, and assign
a variable to it, which is cnt * 0x1000UL. And assign spapr-vio
address to VIO devices, such as spapr-vlan and spapr-vty. Several
test cases are modified.
Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
---
src/qemu/qemu_command.c | 38 +++++++++++++++-----
.../qemuxml2argv-disk-scsi-vscsi.args | 2 +-
.../qemuxml2argv-pseries-basic.args | 2 +-
.../qemuxml2argv-pseries-vio-user-assigned.args | 4 +--
.../qemuxml2argvdata/qemuxml2argv-pseries-vio.args | 8 ++---
5 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3a92c70..fbff73e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -780,14 +780,25 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def)
{
int i, rc;
int model;
+ int cnt = 0;
/* Default values match QEMU. See spapr_(llan|vscsi|vty).c */
for (i = 0 ; i < def->nnets; i++) {
- rc = qemuAssignSpaprVIOAddress(def, &def->nets[i]->info,
- 0x1000ul);
- if (rc)
- return rc;
+ if (!def->nets[i]->model &&
+ STREQ(def->os.arch, "ppc64") &&
+ STREQ(def->os.machine, "pseries"))
+ strcpy(def->nets[i]->model, "spapr-vlan");
+ if (def->nets[i]->model &&
+ STREQ(def->nets[i]->model, "spapr-vlan")) {
+ cnt ++;
+ def->nets[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
+ rc = qemuAssignSpaprVIOAddress(def, &def->nets[i]->info,
+ cnt * 0x1000ul);
+ if (rc)
+ return rc;
+ }
+
}
for (i = 0 ; i < def->ncontrollers; i++) {
@@ -797,19 +808,28 @@ int qemuDomainAssignSpaprVIOAddresses(virDomainDefPtr def)
model = qemuDefaultScsiControllerModel(def);
if (model == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI &&
def->controllers[i]->type == VIR_DOMAIN_CONTROLLER_TYPE_SCSI) {
+ cnt ++;
def->controllers[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
rc = qemuAssignSpaprVIOAddress(def, &def->controllers[i]->info,
- 0x2000ul);
+ cnt * 0x1000ul);
if (rc)
return rc;
}
}
for (i = 0 ; i < def->nserials; i++) {
- rc = qemuAssignSpaprVIOAddress(def, &def->serials[i]->info,
- 0x30000000ul);
- if (rc)
- return rc;
+ if (STREQ(def->os.arch, "ppc64") &&
+ STREQ(def->os.machine, "pseries"))
+ def->serials[i]->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO;
+
+ if (def->serials[i]->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) {
+ cnt ++;
+ rc = qemuAssignSpaprVIOAddress(def, &def->serials[i]->info,
+ cnt * 0x1000ul);
+ if (rc)
+ return rc;
+ }
+
}
/* No other devices are currently supported on spapr-vio */
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args
index d57159f..1feab49 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-vscsi.args
@@ -1,7 +1,7 @@
LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \
pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor \
unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -device spapr-vscsi,id=scsi0,\
-reg=0x2000 -drive file=/dev/HostVG/QEMUGuest1,if=none,\
+reg=0x1000 -drive file=/dev/HostVG/QEMUGuest1,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=/tmp/scsidisk.img,if=none,id=drive-scsi0-0-3-0 \
-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=3,lun=0,drive=drive-scsi0-0-3-0,id=scsi0-0-3-0 \
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args
index f9aec92..927e014 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-basic.args
@@ -1 +1 @@
-LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-ppc64 -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -usb
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-ppc64 -S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x1000 -usb
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args
index fad4346..8072864 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio-user-assigned.args
@@ -2,11 +2,11 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-p
-S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults \
-chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c \
--device spapr-vscsi,id=scsi0,reg=0x2000 \
+-device spapr-vscsi,id=scsi0,reg=0x1000 \
-device spapr-vscsi,id=scsi1,reg=0x30000000 \
-drive file=/tmp/scsidisk.img,if=none,id=drive-scsi1-0-0-0 \
-device scsi-disk,bus=scsi1.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi1-0-0-0,id=scsi1-0-0-0 \
-chardev pty,id=charserial0 \
-device spapr-vty,chardev=charserial0,reg=0x20000000 \
-chardev pty,id=charserial1 \
--device spapr-vty,chardev=charserial1,reg=0x30001000 -usb
+-device spapr-vty,chardev=charserial1,reg=0x4000 -usb
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args
index a75b428..458a1fe 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-pseries-vio.args
@@ -2,11 +2,11 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu-system-p
-S -M pseries -m 512 -smp 1 -nographic -nodefconfig -nodefaults \
-chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=readline -no-acpi -boot c \
--device spapr-vscsi,id=scsi0,reg=0x2000 \
--device spapr-vscsi,id=scsi1,reg=0x3000 \
+-device spapr-vscsi,id=scsi0,reg=0x1000 \
+-device spapr-vscsi,id=scsi1,reg=0x2000 \
-drive file=/tmp/scsidisk.img,if=none,id=drive-scsi1-0-0-0 \
-device scsi-disk,bus=scsi1.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi1-0-0-0,id=scsi1-0-0-0 \
-chardev pty,id=charserial0 \
--device spapr-vty,chardev=charserial0,reg=0x30000000 \
+-device spapr-vty,chardev=charserial0,reg=0x3000 \
-chardev pty,id=charserial1 \
--device spapr-vty,chardev=charserial1,reg=0x30001000 -usb
+-device spapr-vty,chardev=charserial1,reg=0x4000 -usb
--
1.7.9.5
13 years, 1 month
[libvirt] [PATCH 1/1] Fix cpu check for ppc64
by Li Zhang
ppc64 pseries architecture requires that the cpus
be numbered in a certain way.
According to SMT, if SMT equals 4, 0-3 on core 0,
4-7 on core 1 and so on. So, depending on how guest
topology has been specified, one cannot assume that
the vcpus will be numbered 0-N. For example, for
smp=2, core=2, threads=1, the two cpus will be 0 and
4 - one HW thread on each core. libvirt needs to take
into account.
Signed-off-by: Dipankar <dipankar(a)in.ibm.com>
Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
---
src/qemu/qemu_monitor_json.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index e1f5453..aee5265 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -1231,13 +1231,6 @@ qemuMonitorJSONExtractCPUInfo(virJSONValuePtr reply,
goto cleanup;
}
- if (cpu != i) {
- qemuReportError(VIR_ERR_INTERNAL_ERROR,
- _("unexpected cpu index %d expecting %d"),
- i, cpu);
- goto cleanup;
- }
-
threads[i] = thread;
}
--
1.7.9.5
13 years, 1 month
[libvirt] [PATCHv4 1/2] Add a new param 'vcpu_time' to virDomainGetCPUStats
by Hu Tao
Currently virDomainGetCPUStats gets total cpu usage, which consists
of:
1. vcpu usage: the physical cpu time consumed by virtual cpu(s) of
domain
2. hypervisor: `total cpu usage' - `vcpu usage'
The param 'vcpu_time' is for getting vcpu usages.
---
include/libvirt/libvirt.h.in | 6 ++++++
tools/virsh.c | 14 ++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index ac5df95..2449cee 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1355,6 +1355,12 @@ int virDomainGetState (virDomainPtr domain,
*/
#define VIR_DOMAIN_CPU_STATS_SYSTEMTIME "system_time"
+/**
+ * VIR_DOMAIN_CPU_STATS_VCPUTIME:
+ * vcpu usage in nanoseconds, as a ullong
+ */
+#define VIR_DOMAIN_CPU_STATS_VCPUTIME "vcpu_time"
+
int virDomainGetCPUStats(virDomainPtr domain,
virTypedParameterPtr params,
unsigned int nparams,
diff --git a/tools/virsh.c b/tools/virsh.c
index dd9292a..b9d05a2 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -5572,6 +5572,7 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd)
virTypedParameterPtr params = NULL;
int i, j, pos, max_id, cpu = -1, show_count = -1, nparams;
bool show_total = false, show_per_cpu = false;
+ unsigned int flags = 0;
if (!vshConnectionUsability(ctl, ctl->conn))
return false;
@@ -5599,13 +5600,13 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd)
cpu = 0;
/* get number of cpus on the node */
- if ((max_id = virDomainGetCPUStats(dom, NULL, 0, 0, 0, 0)) < 0)
+ if ((max_id = virDomainGetCPUStats(dom, NULL, 0, 0, 0, flags)) < 0)
goto failed_stats;
if (show_count < 0 || show_count > max_id)
show_count = max_id;
/* get percpu information */
- if ((nparams = virDomainGetCPUStats(dom, NULL, 0, 0, 1, 0)) < 0)
+ if ((nparams = virDomainGetCPUStats(dom, NULL, 0, 0, 1, flags)) < 0)
goto failed_stats;
if (!nparams) {
@@ -5619,7 +5620,7 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd)
while (show_count) {
int ncpus = MIN(show_count, 128);
- if (virDomainGetCPUStats(dom, params, nparams, cpu, ncpus, 0) < 0)
+ if (virDomainGetCPUStats(dom, params, nparams, cpu, ncpus, flags) < 0)
goto failed_stats;
for (i = 0; i < ncpus; i++) {
@@ -5630,7 +5631,8 @@ cmdCPUStats(vshControl *ctl, const vshCmd *cmd)
for (j = 0; j < nparams; j++) {
pos = i * nparams + j;
vshPrint(ctl, "\t%-12s ", params[pos].field);
- if (STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME) &&
+ if ((STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME) ||
+ STREQ(params[pos].field, VIR_DOMAIN_CPU_STATS_CPUTIME)) &&
params[j].type == VIR_TYPED_PARAM_ULLONG) {
vshPrint(ctl, "%9lld.%09lld seconds\n",
params[pos].value.ul / 1000000000,
@@ -5653,7 +5655,7 @@ do_show_total:
goto cleanup;
/* get supported num of parameter for total statistics */
- if ((nparams = virDomainGetCPUStats(dom, NULL, 0, -1, 1, 0)) < 0)
+ if ((nparams = virDomainGetCPUStats(dom, NULL, 0, -1, 1, flags)) < 0)
goto failed_stats;
if (!nparams) {
@@ -5665,7 +5667,7 @@ do_show_total:
goto failed_params;
/* passing start_cpu == -1 gives us domain's total status */
- if ((nparams = virDomainGetCPUStats(dom, params, nparams, -1, 1, 0)) < 0)
+ if ((nparams = virDomainGetCPUStats(dom, params, nparams, -1, 1, flags)) < 0)
goto failed_stats;
vshPrint(ctl, _("Total:\n"));
--
1.7.4.4
13 years, 1 month
[libvirt] live migration copy-storage-all , inc
by Pankaj Rawat
Hi all,
I am currently doing live migration task KVM/qemu based virtual machine
I want to know what is exact difference between following:
copy-storage-all option and copy-storage-inc option
what are necessary steps for doing both?
as per my knowledge 'copy-stoarage -all' migrates whole disk image to destination where 'copy-storage-inc' is when we use backing files for guest .
with copy-storage-inc we require backing image on both destination and source but I want to know how destination guest get its base image how they share base image?
Is there any link need to be created for this base image? or is there need for NFS ?
How to set up both options ? what are necessary steps need to follow before starting migration ?
Please help me!
Regards
Pankaj Rawat
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only.
It shall not attach any liability on the originator or NECHCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of NECHCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. .
-----------------------------------------------------------------------------------------------------------------------
13 years, 1 month
[libvirt] ANNOUNCE: libvirt 0.9.11.3 maintenance release
by Cole Robinson
libvirt 0.9.11.3 maintenance release is now available (actually,
available since April 27 but I neglected to send this mail). This is
libvirt 0.9.11 with additional bugfixes that have accumulated
upstream since the initial release.
This release can be downloaded at:
http://libvirt.org/sources/stable_updates/libvirt-0.9.11.3.tar.gz
List of changes since libvirt-0.9.11.2:
* Stable release 0.9.11.3
* python: Fix doc directory name for stable releases
* docs: Serialize running apibuild.py
* configure: Use ustar format for dist tarball
* qemu: improve errors related to offline domains
* nwfilter: address more coverity findings
* nwfilter: address coverity findings
* util: fix error messages in virNetlinkEventServiceStart
For info about past maintenance releases, see:
http://wiki.libvirt.org/page/Maintenance_Releases
Thanks,
Cole
13 years, 1 month
[libvirt] [PATCH] qemu: Don't delete USB device on failed qemuPrepareHostdevUSBDevices
by Michal Privoznik
If qemuPrepareHostdevUSBDevices fail it will roll back devices added
to the driver list of used devices. However, if it may fail because
the device is being used already. But then again - with roll back.
Therefore don't try to remove a usb device manually if the function
fail. Although, we want to remove the device if any operation
performed afterwards fail.
---
src/qemu/qemu_hotplug.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 9b60816..dfca7e2 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1173,8 +1173,10 @@ int qemuDomainAttachHostDevice(struct qemud_driver *driver,
goto cleanup;
}
- if (qemuPrepareHostdevUSBDevices(driver, vm->def->name, list) < 0)
+ if (qemuPrepareHostdevUSBDevices(driver, vm->def->name, list) < 0) {
+ usb = NULL;
goto cleanup;
+ }
usbDeviceListSteal(list, usb);
}
--
1.7.8.5
13 years, 1 month
[libvirt] [PATCH 0/6] support to set cpu bandwidth for hypervisor threads
by Wen Congyang
Currently, we only can set cpu bandwidth for vcpu. If the hypervisor threads
consume too much cpu time, it may affect the vcpu.
This patchset allows the user to control the cpu bandwidth for hypervisor
threads. It does not change the behavior if the cpu bandwidth for hypervisor
is unlimited.
Wen Congyang (6):
Introduce the function virCgroupForHypervisor
introduce the function virCgroupMoveTask()
create a new cgroup and move all hypervisor threads to the new cgroup
Update XML Schema for new entries
qemu: Implement hypervisor's period and quota tunable XML
configuration and parsing
qemu: Implement hypervisor_period and hypervisor_quota's modification
docs/schemas/domaincommon.rng | 10 ++
include/libvirt/libvirt.h.in | 16 +++
src/conf/domain_conf.c | 25 +++++-
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_cgroup.c | 94 +++++++++++++++--
src/qemu/qemu_cgroup.h | 2 +
src/qemu/qemu_driver.c | 220 +++++++++++++++++++++++++++++++++++-----
src/qemu/qemu_process.c | 4 +
src/util/cgroup.c | 97 ++++++++++++++++++
src/util/cgroup.h | 6 +
11 files changed, 436 insertions(+), 41 deletions(-)
13 years, 1 month
Re: [libvirt] libvirt chowning my kernel/initrd files
by Seth Jennings
On Wed, May 16, 2012 at 2:31 PM, Eric Blake <eblake(a)redhat.com> wrote:
> On 05/16/2012 11:19 AM, Seth Jennings wrote:
>> On Wed, May 16, 2012 at 12:06 PM, Eric Blake <eblake(a)redhat.com> wrote:
>>> On 05/16/2012 10:30 AM, Seth Jennings wrote:
> Did you mean for this replay to go to the list?
Yes I did :-/ Back on the list.
> You might also want to play with dynamic_ownership in
> /etc/libvirt/qemu.conf, which changes whether libvirtd will chown in the
> first place.
That does the trick. Although, without dynamic_ownership,
libvirt-qemu doesn't have write access to the LV I'm using as a virtio
disk. So I guess it's a two edged sword. However, manually adding
the libvirt-qemu user to the disk group fixed that. Might be a
little coarse security-wise, but I don't feel like writing new udev
rules for the device mapper today.
<snip>
> At least read access is required, for the uid that qemu will be running
> as. If the file permissions _already_ grants read access, and libvirt
> isn't recognizing that fact but doing the chown anyways, then that would
> be something worth cleaning up.
That is the case; it is chowning things even if it has the access
required. Additionally, at least in Ubuntu 12.04, it does _not_
restore the original ownership. The initial chown when the VM starts
is to libvirt-qemu:kvm, and once the VM shuts down, the ownership
switches to root:root, regardless of the original ownership.
Honestly, this could be used for privilege escalation of sorts. If I
was a member of the libvirtd group, I could target a file owned by
another user by making it the kernel for a VM and starting it. Of
course, the VM wouldn't boot (unless the target file was actually a
kernel image), but I would have successfully chowned that file to
root:root using libvirtd, which runs a root, to do it. The user that
originally owned the file would no longer be the owner.
Thanks,
Seth
13 years, 1 month
[libvirt] lxc: Create /dev/tty automatically ?
by Sukadev Bhattiprolu
Hi,
(I posted this on libvirt-users but its more a development question)
src/lxc/lxc_container.c:lxcContainerPopulateDevices() has this table
of devices that are automatically created when an lxc container is
started.
const struct {
int maj;
int min;
mode_t mode;
const char *path;
} devs[] = {
{ LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_NULL, 0666, "/dev/null" },
{ LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_ZERO, 0666, "/dev/zero" },
{ LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_FULL, 0666, "/dev/full" },
{ LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_RANDOM, 0666, "/dev/random" },
{ LXC_DEV_MAJ_MEMORY, LXC_DEV_MIN_URANDOM, 0666, "/dev/urandom" },
};
Can we add '/dev/tty' to this list ?
We were trying to run 'smbpasswd -a user' inside a container without
/dev/tty and the fopen("/dev/tty", "w+") in smbpasswd made /dev/tty
a regular file, breaking man(1), less(1), and ofcourse smbpasswd :-)
Sure we can add /dev/tty to container's rc.local or something, but
wouldn't it be in the same category as say, /dev/null or /dev/zero ?
Sukadev
13 years, 1 month
