- Devel - libvirt List Archives

[libvirt] [PATCH 1/5] virerror: Fix an error message typo
by Cole Robinson 07 May '14

07 May '14

--- src/util/virerror.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virerror.h b/src/util/virerror.h index 2de04f4..fe0e15e 100644 --- a/src/util/virerror.h +++ b/src/util/virerror.h @@ -99,7 +99,7 @@ void virReportSystemErrorFull(int domcode, #argname, \ NULL, \ 0, 0, \ - _("%s in %s must greater than zero"), \ + _("%s in %s must be greater than zero"), \ #argname, __FUNCTION__) # define virReportInvalidNonZeroArg(argname) \ virRaiseErrorFull(__FILE__, __FUNCTION__, __LINE__, \ -- 1.9.0

3 12

[libvirt] [PATCH 0/2] Fix bug on buildVol error path
by John Ferlan 07 May '14

07 May '14

https://bugzilla.redhat.com/show_bug.cgi?id=1092882 Changes as a result of commit id '0c2305b3', see: http://www.redhat.com/archives/libvir-list/2014-April/msg00375.html Resulted in a regression when there was a failure to buildVol the volume wasn't removed from the storage driver list because the wrong local storage pointer was passed to the DeleteInternal routine. Additionally a preexisting condition where if deleteVol didn't exist or failed, the volume would not be removed from volumes.objs[] even though it doesn't exist. This results in virsh vol-list and vol-info not finding the volume and emitting error messages. John Ferlan (2): storage: Need to ensure removal of voldef from driver list storage: Resolve issues in failure path src/storage/storage_driver.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) -- 1.9.0

2 5

[libvirt] [RESEND PATCH] Add support for timestamping QEMU logs
by Ján Tomko 07 May '14

07 May '14

QEMU commit 5e2ac51 added a boolean '-msg timestamp=[on|off]' option, which can enable timestamps on errors: $ qemu-system-x86_64 -msg timestamp=on zghhdorf 2014-04-09T13:25:46.779484Z qemu-system-x86_64: -msg timestamp=on: could not open disk image zghhdorf: Could not open 'zghhdorf': No such file or directory Enable this timestamp if the QEMU binary supports it. Add a 'log_timestamp' option to qemu.conf for disabling this behavior. --- Rebased to latest master, this time with the test files added. previous posting of the patch: https://www.redhat.com/archives/libvir-list/2014-April/msg00422.html src/qemu/libvirtd_qemu.aug | 3 ++ src/qemu/qemu.conf | 8 ++++++ src/qemu/qemu_capabilities.c | 5 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 4 +++ src/qemu/qemu_conf.c | 4 +++ src/qemu/qemu_conf.h | 2 ++ src/qemu/test_libvirtd_qemu.aug.in | 1 + tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 1 + .../qemuxml2argv-minimal-msg-timestamp.args | 6 ++++ .../qemuxml2argv-minimal-msg-timestamp.xml | 32 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 13 files changed, 69 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.xml diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug index a9ff421..e985d22 100644 --- a/src/qemu/libvirtd_qemu.aug +++ b/src/qemu/libvirtd_qemu.aug @@ -85,6 +85,8 @@ module Libvirtd_qemu = | int_entry "migration_port_min" | int_entry "migration_port_max" + let log_entry = bool_entry "log_timestamp" + (* Each entry in the config is one of the following ... *) let entry = vnc_entry | spice_entry @@ -96,6 +98,7 @@ module Libvirtd_qemu = | device_entry | rpc_entry | network_entry + | log_entry let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ] let empty = [ label "#empty" . eol ] diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf index f0e802f..42f812d 100644 --- a/src/qemu/qemu.conf +++ b/src/qemu/qemu.conf @@ -465,3 +465,11 @@ # #migration_port_min = 49152 #migration_port_max = 49215 + + + +# Timestamp QEMU's log messages (if QEMU supports it) +# +# Defaults to 1. +# +#log_timestamp = 0 diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 8343258..0d08e20 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -255,6 +255,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "usb-kbd", /* 165 */ "host-pci-multidomain", + "msg-timestamp", ); @@ -1146,6 +1147,9 @@ virQEMUCapsComputeCmdFlags(const char *help, if (strstr(help, "-machine")) virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_OPT); + if (strstr(help, "-msg timestamp")) + virQEMUCapsSet(qemuCaps, QEMU_CAPS_MSG_TIMESTAMP); + /* * Handling of -incoming arg with varying features * -incoming tcp (kvm >= 79, qemu >= 0.10.0) @@ -2378,6 +2382,7 @@ static struct virQEMUCapsCommandLineProps virQEMUCapsCommandLine[] = { { "boot-opts", "strict", QEMU_CAPS_BOOT_STRICT }, { "boot-opts", "reboot-timeout", QEMU_CAPS_REBOOT_TIMEOUT }, { "spice", "disable-agent-file-xfer", QEMU_CAPS_SPICE_FILE_XFER_DISABLE }, + { "msg", "timestamp", QEMU_CAPS_MSG_TIMESTAMP }, }; static int diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 26400d2..d755caa 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -205,6 +205,7 @@ enum virQEMUCapsFlags { QEMU_CAPS_CHARDEV_SPICEPORT = 164, /* -chardev spiceport */ QEMU_CAPS_DEVICE_USB_KBD = 165, /* -device usb-kbd */ QEMU_CAPS_HOST_PCI_MULTIDOMAIN = 166, /* support domain > 0 in host pci address */ + QEMU_CAPS_MSG_TIMESTAMP = 167, /* -msg timestamp */ QEMU_CAPS_LAST, /* this must always be the last item */ }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 29ae8e4..dd8e40a 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -9742,6 +9742,10 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandSetMaxMemLock(cmd, memKB * 1024); } + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_MSG_TIMESTAMP) && + cfg->logTimestamp) + virCommandAddArgList(cmd, "-msg", "timestamp=on", NULL); + virObjectUnref(cfg); return cmd; diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 198ee2f..e487f5e 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -255,6 +255,8 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged) cfg->keepAliveCount = 5; cfg->seccompSandbox = -1; + cfg->logTimestamp = true; + return cfg; error: @@ -576,6 +578,8 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg, GET_VALUE_STR("migration_address", cfg->migrationAddress); + GET_VALUE_BOOL("log_timestamp", cfg->logTimestamp); + ret = 0; cleanup: diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index a36ea63..5d2983a 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -167,6 +167,8 @@ struct _virQEMUDriverConfig { char *migrationAddress; int migrationPortMin; int migrationPortMax; + + bool logTimestamp; }; /* Main driver state */ diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index b2328d3..30a4257 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -72,3 +72,4 @@ module Test_libvirtd_qemu = { "migration_address" = "127.0.0.1" } { "migration_port_min" = "49152" } { "migration_port_max" = "49215" } +{ "log_timestamp" = "0" } diff --git a/tests/qemucapabilitiesdata/caps_1.6.0-1.caps b/tests/qemucapabilitiesdata/caps_1.6.0-1.caps index 7b86c3b..ca2c236 100644 --- a/tests/qemucapabilitiesdata/caps_1.6.0-1.caps +++ b/tests/qemucapabilitiesdata/caps_1.6.0-1.caps @@ -143,4 +143,5 @@ <flag name='spiceport'/> <flag name='usb-kbd'/> <flag name='host-pci-multidomain'/> + <flag name='msg-timestamp'/> </qemuCaps> diff --git a/tests/qemucapabilitiesdata/caps_1.6.50-1.caps b/tests/qemucapabilitiesdata/caps_1.6.50-1.caps index 10b8251..32bccdb 100644 --- a/tests/qemucapabilitiesdata/caps_1.6.50-1.caps +++ b/tests/qemucapabilitiesdata/caps_1.6.50-1.caps @@ -141,4 +141,5 @@ <flag name='spiceport'/> <flag name='usb-kbd'/> <flag name='host-pci-multidomain'/> + <flag name='msg-timestamp'/> </qemuCaps> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.args b/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.args new file mode 100644 index 0000000..f85aae9 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.args @@ -0,0 +1,6 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu \ +-name QEMUGuest1 -S -M pc -m 214 -smp 1 -nographic -monitor \ +unix:/tmp/test-monitor,server,nowait -no-acpi -boot c \ +-usb -hda /dev/HostVG/QEMUGuest1 -net none -serial \ +none -parallel none -msg timestamp=on diff --git a/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.xml b/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.xml new file mode 100644 index 0000000..4a938b3 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-minimal-msg-timestamp.xml @@ -0,0 +1,32 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <title>A description of the test machine.</title> + <description> + A test of qemu's minimal configuration. + This test also tests the description and title elements. + </description> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static' cpuset='1-4,8-20,525'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index ad5e2cd..1ea7bf8 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -578,6 +578,7 @@ mymain(void) unsetenv("SDL_AUDIODRIVER"); DO_TEST("minimal", QEMU_CAPS_NAME); + DO_TEST("minimal-msg-timestamp", QEMU_CAPS_NAME, QEMU_CAPS_MSG_TIMESTAMP); DO_TEST("minimal-s390", QEMU_CAPS_NAME); DO_TEST("machine-aliases1", NONE); DO_TEST("machine-aliases2", QEMU_CAPS_KVM); -- 1.8.3.2

2 2

[libvirt] [PATCH RFC 00/22] Support for walking backing chains on remote volumes (especially gluster)
by Peter Krempa 07 May '14

07 May '14

This series adds support for waliking (detecting) of backing chain on remote storage and implements the needed callbacks for the gluster storage system via native library. The last patch in the series mocks up path canonicalization on gluster as I'm working on that but this series is getting tedious to rebase and handle so I'd like to start reviews. Peter Krempa (22): qemu: Make qemuDomainPrepareDiskChainElement aware of remote storage storage: Store gluster volume name separately storage: Rework debugging of storage file access through storage driver conf: Fix domain disk path iterator to work with networked storage storage: Add NONE protocol type for network disks storage: Add support for access to files using provided uid/gid storage: Add storage file API to read file headers storage: backend: Add unique id retrieval API storage: Add API to check accessibility of storage volumes storage: Move virStorageFileGetMetadata to the storage driver storage: Determine the local storage type right away test: storage: Initialize storage source to correct type storage: backend: Add possibility to suppress errors from backend lookup storage: Switch metadata crawler to use storage driver to get unique path storage: Switch metadata crawler to use storage driver to read headers storage: Switch metadata crawler to use storage driver file access check storage: Add infrastructure to parse remote network backing names storage: Change to new backing store parser storage: Traverse backing chains of network disks qemu: Add support for networked disks for block pull/block rebase qemu: Add support for networked disks for block commit [DO NOT APPLY UPSTREAM] storage: gluster: mock up path canonicalization cfg.mk | 2 +- src/Makefile.am | 2 + src/conf/domain_conf.c | 70 +++- src/libvirt_private.syms | 3 +- src/qemu/qemu_command.c | 21 +- src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_driver.c | 116 +++++-- src/security/virt-aa-helper.c | 2 + src/storage/storage_backend.c | 16 +- src/storage/storage_backend.h | 22 +- src/storage/storage_backend_fs.c | 127 +++++++- src/storage/storage_backend_gluster.c | 141 ++++++-- src/storage/storage_driver.c | 329 ++++++++++++++++++- src/storage/storage_driver.h | 15 +- src/util/virstoragefile.c | 596 +++++++++++++++++++++------------- src/util/virstoragefile.h | 16 +- tests/Makefile.am | 7 +- tests/virstoragetest.c | 26 +- 18 files changed, 1162 insertions(+), 359 deletions(-) -- 1.9.2

2 27

[libvirt] [question]qemu: migrate and destory vm immediately on destination causes libvirt deadlock or segment fault
by Wangrui (K) 07 May '14

07 May '14

Hi everyone, I do ram migration operation in KVM environment(libvirt1.2.4 qemu1.5.1). I encountered libvirtd deadlock or segmentfault when I destroy the migration VM on destination. I got the problem by flowing steps: step 1: migrate VM. step 2: execute "virsh destroy [VMName]" to destroy the migration VM on destination immediately. step 3: the destination libvirtd will be probably deadlock or segmentfault. Deadlock stack as followed: #0 0x00007fb5c18132d4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fb5c180e659 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007fb5c180e46e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007fb5c45d175f in virMutexLock (m=0x7fb5b0066ed0) at util/virthread.c:88 #4 0x00007fb5c45b6b04 in virObjectLock (anyobj=0x7fb5b0066ec0) at util/virobject.c:323 #5 0x00007fb5b8f4842a in qemuMonitorEmitEvent (mon=0x7fb5b0066ec0, event=0x7fb5b00688d0 "SHUTDOWN", seconds=1399374472, micros=509994, details=0x0) at qemu/qemu_monitor.c:1185 #6 0x00007fb5b8f62af2 in qemuMonitorJSONIOProcessEvent (mon=0x7fb5b0066ec0, obj=0x7fb5b0069080) at qemu/qemu_monitor_json.c:158 #7 0x00007fb5b8f62d25 in qemuMonitorJSONIOProcessLine (mon=0x7fb5b0066ec0, line=0x7fb5b005bbe0 "{\"timestamp\": {\"seconds\": 1399374472, \"microseconds\": 509994}, \"event\": \"SHUTDOWN\"}",msg=0x7fb5bd873c80) at qemu/qemu_monitor_json.c:195 #8 0x00007fb5b8f62f85 in qemuMonitorJSONIOProcess (mon=0x7fb5b0066ec0, data=0x7fb5b0060770 "{\"timestamp\": {\"seconds\": 1399374472, \"microseconds\": 509994},\"event\": \"SHUTDOWN\"}\r\n", len=85, msg=0x7fb5bd873c80) at qemu/qemu_monitor_json.c:237 #9 0x00007fb5b8f49aa0 in qemuMonitorIOProcess (mon=0x7fb5b0066ec0) at qemu/qemu_monitor.c:402 #10 0x00007fb5b8f4a09b in qemuMonitorIO (watch=20, fd=24, events=0, opaque=0x7fb5b0066ec0) at qemu/qemu_monitor.c:651 #11 0x00007fb5c458c4d9 in virEventPollDispatchHandles (nfds=17, fds=0x7fb5b0068a60) at util/vireventpoll.c:510 #12 0x00007fb5c458decf in virEventPollRunOnce () at util/vireventpoll.c:659 #13 0x00007fb5c458bfcc in virEventRunDefaultImpl () at util/virevent.c:308 #14 0x00007fb5c51a17a9 in virNetServerRun (srv=0x7fb5c5411d70) at rpc/virnetserver.c:1139 #15 0x00007fb5c5157f63 in main (argc=3, argv=0x7fff7fc04f48) at libvirtd.c:150 After analysis, I found it may be caused by multithreaded simultaneously access to the global variables "vm->privateData->mon". When problems occur，there are three libvirtd threads at work on destination host，suppose： ThreadA: migration thread，do qemuProcessStart. ThreadB: destroy thread，do qemuDoaminDestroy -> qemuProcessStop. ThreadC：Monitor Thread，do IOWrite、IORead and some other operations according to the mon->msg when mon->fd change. When threadB destroy happpens, this thread would handle the SUHTDOWN event. In threadA, when it sends QMP command to Qemu, it will operate the vm->privateData->mon lock. Such as the operation "qemuDomainObjEnterMonitor -> qemuMonitorSetBalloon -> qemuDomainObjExitMonitor", but it's not an atomic operation. If "virsh destroy [VMName]" happens during this operation, threadB will set the lock vm->privateData->mon to NULL in qemuProcessStop. And then in threadA, the function qemuDomainObjExitMonitor will fail to unlock vm->privateData->mon as it's NULL. So, threadC will never acquire the vm->privateData->mon lock and the deadlock problem happened. what was worse, if qemuMonitorSetBalloon perform succeed in threadA. ThreadA will coutinue to execute till it enter the function qemuMonitorSetDomainLog, it would cause segmentfault at VIR_FORCE_CLOSE(mon->logfd) due to mon is NULL. I could not find a good way to sovle this problem. Does anyone have good ideas? Thanks. Ps: I find an easy way to reproduce this problem more probably by following steps: step 1: Fault Injection, fit into this patch and update the libvirtd on destination host: --- src/qemu/qemu_process.c 2014-05-06 19:06:00.000000000 +0800 +++ src/qemu/qemu_process.c 2014-05-06 19:07:12.000000000 +0800 @@ -4131,6 +4131,8 @@ vm->def->mem.cur_balloon); goto cleanup; } + VIR_DEBUG("Fault Injection, sleep 3 seconds."); + sleep(3); qemuDomainObjEnterMonitor(driver, vm); if (vm->def->memballoon && vm->def->memballoon->period) qemuMonitorSetMemoryStatsPeriod(priv->mon, vm->def->memballoon->period); step 2: migrate VM. step 3: execute "virsh destroy [VMName]" to destroy the migration VM on destination when log prints "Fault Injection, sleep 3 seconds." step 4: the libvirtd deadlock stack occurs as above mentioned. Regards

1 0

[libvirt] Virsh Attach Volume Fails
by Vilobh Meshram 07 May '14

07 May '14

Hi, When trying to attach a created volume to an instance using the virsh utility I am running into this error :- [] $ sudo virsh attach-device instance-00000015 disk.xml error: Failed to attach device from disk.xml error: internal error unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk21' could not be initialized For experimental purpose I have libvirt 0.10.2 and QEMU 0.12.1. The volume to be attached is on a remote storage. Any idea what I might be missing ? Thanks, Vilobh

2 2

[libvirt] [libvirt PATCH] udev: consider the device a CDROM when ID_CDROM=1
by Giuseppe Scrivano 07 May '14

07 May '14

Some CDROM devices are reported by udev to have an ID_TYPE="generic" thus it is necessary to check if ID_CDROM is present. As a side effect, treating ID_TYPE="generic" as a missing ID_TYPE will enable checks for ID_DRIVE_FLASH_SD and ID_DRIVE_FLOPPY and the udevKludgeStorageType heuristic. Signed-off-by: Giuseppe Scrivano <gscrivan(a)redhat.com> --- src/node_device/node_device_udev.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 71b3c79..de1cc67 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1,7 +1,7 @@ /* * node_device_udev.c: node device enumeration - libudev implementation * - * Copyright (C) 2009-2013 Red Hat, Inc. + * Copyright (C) 2009-2014 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -1093,7 +1093,8 @@ static int udevProcessStorage(struct udev_device *device, if (udevGetStringProperty(device, "ID_TYPE", - &data->storage.drive_type) != PROPERTY_FOUND) { + &data->storage.drive_type) != PROPERTY_FOUND + || STREQ(def->caps->data.storage.drive_type, "generic")) { int tmp_int = 0; /* All floppy drives have the ID_DRIVE_FLOPPY prop. This is @@ -1104,6 +1105,12 @@ static int udevProcessStorage(struct udev_device *device, if (VIR_STRDUP(data->storage.drive_type, "floppy") < 0) goto out; + } else if ((udevGetIntProperty(device, "ID_CDROM", + &tmp_int, 0) == PROPERTY_FOUND) && + (tmp_int == 1)) { + + if (VIR_STRDUP(data->storage.drive_type, "cd") < 0) + goto out; } else if ((udevGetIntProperty(device, "ID_DRIVE_FLASH_SD", &tmp_int, 0) == PROPERTY_FOUND) && (tmp_int == 1)) { -- 1.9.0

3 5

[libvirt] [PATCH] docs: update README-hacking
by Chen Hanxiao 07 May '14

07 May '14

We didn't have "README-valgrind" file now. So remove related description. Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> --- README-hacking | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-hacking b/README-hacking index 80b022c..4e02fd8 100644 --- a/README-hacking +++ b/README-hacking @@ -15,7 +15,7 @@ Specific development tools and versions will be checked for and listed by the bootstrap script. Valgrind <http://valgrind.org/> is also highly recommended, if -Valgrind supports your architecture. See also README-valgrind. +Valgrind supports your architecture. While building from a just-cloned source tree may require installing a few prerequisites, later, a plain `git pull && make' should be sufficient. -- 1.9.0

3 2

[libvirt] [PATCH] PCI: Introduce new device binding path using pci_dev.driver_override
by Alex Williamson 06 May '14

06 May '14

The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo > /sys/bus/pci/devices/0000:03:00.0/preferred_driver echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (preferred driver = "none") or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- Changes since RFC: - Add ABI documentation (gregkh) - Documentation wording clarification (Christoffer) Nobody puked on the RFC and platform folks have posted a working version of this for platform devices, so I guess the only thing left to do is formally propose this as a new driver binding mechanism. I don't see much incentive to push this into the driver core since the match ultimately needs to be done by the bus driver. I think this is therefore like new_id/remove_id where PCI and USB implement separate, but consistent interfaces. I've pruned the CC list a bit from the RFC, but I've added libvirt folks since I expect they would be the first userspace tool that would adopt this. Thanks, Alex Documentation/ABI/testing/sysfs-bus-pci | 21 ++++++++++++++++ drivers/pci/pci-driver.c | 25 +++++++++++++++++-- drivers/pci/pci-sysfs.c | 40 +++++++++++++++++++++++++++++++ include/linux/pci.h | 1 + 4 files changed, 84 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson <alex.williamson(a)redhat.com> +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub > driver_override) and + may be cleared with an empty string (echo > driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + "none". Only a single driver may be specified in the override, + there is no support for parsing delimiters. diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 25f0bc6..f780eb8 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -216,6 +216,13 @@ const struct pci_device_id *pci_match_id(const struct pci_device_id *ids, return NULL; } +static const struct pci_device_id pci_device_id_any = { + .vendor = PCI_ANY_ID, + .device = PCI_ANY_ID, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, +}; + /** * pci_match_device - Tell if a PCI device structure has a matching PCI device id structure * @drv: the PCI driver to match against @@ -229,18 +236,30 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv, struct pci_dev *dev) { struct pci_dynid *dynid; + const struct pci_device_id *found_id = NULL; + + /* When driver_override is set, only bind to the matching driver */ + if (dev->driver_override && strcmp(dev->driver_override, drv->name)) + return NULL; /* Look at the dynamic ids first, before the static ones */ spin_lock(&drv->dynids.lock); list_for_each_entry(dynid, &drv->dynids.list, node) { if (pci_match_one_device(&dynid->id, dev)) { - spin_unlock(&drv->dynids.lock); - return &dynid->id; + found_id = &dynid->id; + break; } } spin_unlock(&drv->dynids.lock); - return pci_match_id(drv->id_table, dev); + if (!found_id) + found_id = pci_match_id(drv->id_table, dev); + + /* driver_override will always match, send a dummy id */ + if (!found_id && dev->driver_override) + found_id = &pci_device_id_any; + + return found_id; } struct drv_dev_and_id { diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 276ef9c..70cb39d 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -510,6 +510,45 @@ static struct device_attribute sriov_numvfs_attr = sriov_numvfs_show, sriov_numvfs_store); #endif /* CONFIG_PCI_IOV */ +static ssize_t driver_override_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct pci_dev *pdev = to_pci_dev(dev); + char *driver_override, *old = pdev->driver_override; + + if (count > PATH_MAX) + return -EINVAL; + + driver_override = kstrndup(buf, count, GFP_KERNEL); + if (!driver_override) + return -ENOMEM; + + while (strlen(driver_override) && + driver_override[strlen(driver_override) - 1] == '\n') + driver_override[strlen(driver_override) - 1] = '\0'; + + if (strlen(driver_override)) { + pdev->driver_override = driver_override; + } else { + kfree(driver_override); + pdev->driver_override = NULL; + } + + kfree(old); + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct pci_dev *pdev = to_pci_dev(dev); + + return sprintf(buf, "%s\n", pdev->driver_override); +} +static DEVICE_ATTR_RW(driver_override); + static struct attribute *pci_dev_attrs[] = { &dev_attr_resource.attr, &dev_attr_vendor.attr, @@ -532,6 +571,7 @@ static struct attribute *pci_dev_attrs[] = { #if defined(CONFIG_PM_RUNTIME) && defined(CONFIG_ACPI) &dev_attr_d3cold_allowed.attr, #endif + &dev_attr_driver_override.attr, NULL, }; diff --git a/include/linux/pci.h b/include/linux/pci.h index 33aa2ca..6b666af 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -364,6 +364,7 @@ struct pci_dev { #endif phys_addr_t rom; /* Physical address of ROM if it's not from the BAR */ size_t romlen; /* Length of ROM if it's not from the BAR */ + char *driver_override; /* Driver name to force a match */ }; static inline struct pci_dev *pci_physfn(struct pci_dev *dev)

3 4

[libvirt] LSN-2014-0003: Unsafe parsing of XML documents allows arbitrary file read
by Daniel P. Berrange 06 May '14

06 May '14

Libvirt Security Notice: LSN-2014-0003 ====================================== Summary: Unsafe parsing of XML documents allows arbitrary file read Reported on: 20140411 Published on: 20140506 Fixed on: 20140506 Reported by: Daniel P. Berrange <berrange(a)redhat.com> Richard Jones <rjones(a)redhat.com> Patched by: Daniel P. Berrange <berrange(a)redhat.com> See also: CVE-2014-0179 Description ----------- When parsing XML documents, libvirt passes the XML_PARSE_NOENT flag to libxml2 which instructs it to expand all entities in the XML document during parsing. This can be used to insert the contents of host OS files in the resulting parsed content. Although the flaw was introduced in 0.0.5, it was dormant having no ill effects, since the APIs involved all required the user to authenticate with privileges equivalent to root. In version 0.7.5 or later the virConnectCompareCPU / virConnectBaselineCPU methods activate the dormant bug, allowing for denial of service. In version 1.0.0 or later, if the admin opts in to using the new fine grained access control feature, there is potential for unprivileged information disclosure. Impact ------ A malicious user can pass libvirt an XML document which contains an entity that points to an arbitrary file on the host. When libvirt parses this document, it will insert the contents of that host file, which could allow the user to read the contents of files that they otherwise do not have permission to view. It also has the potential to cause a denial of service / indefinite hang of libvirt, if the entity points to a named pipe with no writer connected or certain proc files. If the libvirt installation is not using fine grained access control then virConnectCompareCPU and virConnectBaselineCPU APIs can be used by a read-only user to inflict a denial of service attack. If the libvirt installation is using fine grained access control, then as well as the denial of service attack, one or more of the following APIs can be used for information disclosure of files: virDomainDefineXML, virNetworkCreateXML, virNetworkDefineXML, virStoragePoolCreateXML, virStoragePoolDefineXML, virStorageVolCreateXML, virDomainCreateXML, virNodeDeviceCreateXML, virInterfaceDefineXML, virStorageVolCreateXMLFrom, virConnectDomainXMLFromNative, virConnectDomainXMLToNative, virSecretDefineXML, virNWFilterDefineXML, virDomainSnapshotCreateXML, virDomainSaveImageDefineXML, virDomainCreateXMLWithFiles, virConnectCompareCPU, virConnectBaselineCPU. Workaround ---------- Stop use of the fine grained access control mechanism, and restrict access to all the libvirt TCP/UNIX sockets to only trusted authenticated users. Simply denying access to the affected APIs in the access control policy is insufficient to mitigate the bug, since the XML document typically needs to be parsed before the access control check is applied in order to extra the UUID/name of the object to check. Access to the readonly libvirt socket must also be revoked Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v0.7.5 Broken in: v0.7.6 Broken in: v0.7.7 Broken in: v0.8.0 Broken in: v0.8.1 Broken in: v0.8.2 Broken in: v0.8.3 Broken in: v0.8.4 Broken in: v0.8.5 Broken in: v0.8.6 Broken in: v0.8.7 Broken in: v0.8.8 Broken in: v0.9.0 Broken in: v0.9.1 Broken in: v0.9.2 Broken in: v0.9.3 Broken in: v0.9.4 Broken in: v0.9.5 Broken in: v0.9.6 Broken in: v0.9.7 Broken in: v0.9.8 Broken in: v0.9.9 Broken in: v0.9.10 Broken in: v0.9.11 Broken in: v0.9.12 Broken in: v0.9.13 Broken in: v1.0.0 Broken in: v1.0.1 Broken in: v1.0.2 Broken in: v1.0.3 Broken in: v1.0.4 Broken in: v1.0.5 Broken in: v1.0.6 Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: d6b27d3e4c40946efa79e91d134616b41b1666c4 Branch: v0.9.6-maint Broken in: v0.9.6.1 Broken in: v0.9.6.2 Broken in: v0.9.6.3 Broken in: v0.9.6.4 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Fixed by: be7a5de9d0c406f36efae3230e1743c613ad6945 Branch: v0.9.11-maint Broken in: v0.9.11.1 Broken in: v0.9.11.2 Broken in: v0.9.11.3 Broken in: v0.9.11.4 Broken in: v0.9.11.5 Broken in: v0.9.11.6 Broken in: v0.9.11.7 Broken in: v0.9.11.8 Broken in: v0.9.11.9 Broken in: v0.9.11.10 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Branch: v0.9.12-maint Broken in: v0.9.12.1 Broken in: v0.9.12.2 Broken in: v0.9.12.3 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Fixed by: 022b34cee73f86b01724b5279cf626df9cca245f Branch: v1.0.5-maint Broken in: v1.0.5.1 Broken in: v1.0.5.2 Broken in: v1.0.5.3 Broken in: v1.0.5.4 Broken in: v1.0.5.5 Broken in: v1.0.5.6 Broken in: v1.0.5.7 Broken in: v1.0.5.8 Broken in: v1.0.5.9 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Fixed by: 4410a83e18c1b41f1f5d3f10a0b648fc9304bc35 Branch: v1.1.0-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: 6f4eae73a0bf3e1c5e9597e4f9a8078cad69b1e3 Branch: v1.1.1-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: cfc94140e5989c9f3cce0fdbb758730818cb2572 Branch: v1.1.2-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: 8fd2005cc0594742dc6cfab07a62f9774798a56d Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: 46de45d079ae2622660fe147cf237ee617cc461c Branch: v1.1.4-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: e2b96d539f8a06e08cdf001627efe3f399db9c07 Branch: v1.2.0-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: 9b1d09377492a4ce92498abb7cf830d693bc661c Branch: v1.2.1-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: 877388678a77bacf802f97de429b2b350b02eb41 Branch: v1.2.2-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: ab07ebeb22b1d724999dc6eabc33cd6266de496f Branch: v1.2.3-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: a45368839fb898feb6b634df2bf337697155ea74 Branch: v1.2.4-maint Broken by: 77e8b6c62c48b6346bbdb2df3e0d925852c6bf3e Broken by: 387941fb626d9362835aa216b4a871e18268f649 Broken by: 0b7d2ae653f583825f6d83bfb0744673648a9833 Broken by: ed3bac713c3cfc055ef551cbfe92a061084382c3 Fixed by: a8480e2bc0d0b1c5cd98ff7424cace3e82db5ace Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0