March 2018 - Devel - libvirt List Archives

[libvirt] [PATCH] remote: remove outdated comment about Solaris
by Daniel P. Berrangé 28 Mar '18

28 Mar '18

When removing a conditional in: commit da1ade7a52e040192c5e9396c15ec9225a0a2c48 Author: Daniel P. Berrangé <berrange(a)redhat.com> Date: Fri Mar 23 10:50:59 2018 +0000 remote: remove some __sun conditionals the corresponding comment was mistakenly left behind. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as trivial fix. src/remote/remote_driver.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 34e5ced0a9..325ef3fa3d 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -1344,9 +1344,7 @@ remoteConnectOpen(virConnectPtr conn, /* * If URI is NULL, then do a UNIX connection possibly auto-spawning - * unprivileged server and probe remote server for URI. On Solaris, - * this isn't supported, but we may be privileged enough to connect - * to the UNIX socket anyway. + * unprivileged server and probe remote server for URI. */ if (!conn->uri) { VIR_DEBUG("Auto-probe remote URI"); -- 2.14.3

1 0

[libvirt] [PATCH v2 0/3] Introduce hot plug support for mediated devices
by Erik Skultety 28 Mar '18

28 Mar '18

Libvirt shouldn't forbid the operation as unsupported. In fact, from VFIO point of view, mdevs have supported hot plug since the beginning. Then it's up to the 3rd party vendor driver whether it can cope with this feature reliably or not. Since v1 [1]: - dropped the original patch 1 as that adjustment can be done in a bigger scale across multiple modules as part of a 'bite-sized' task - reworded commit message for patches 2 and 3 - fixed the error path in patch 1 where I mistakenly tried to re-attach all host devices for a domain if the hotplug of an mdev failed [1] https://www.redhat.com/archives/libvir-list/2018-March/msg01631.html Erik Skultety (3): qemu: hotplug: Introduce hot plug support for mediated devices qemu: hotplug: Introduce hot unplug for mediated devices news: Update release news with mediated devices hot {plug,unplug} docs/news.xml | 10 ++++ src/qemu/qemu_hotplug.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+) -- 2.14.3

2 5

[libvirt] [PATCH v2 0/3] Improve handling of multipath devices
by Michal Privoznik 28 Mar '18

28 Mar '18

v2 of: https://www.redhat.com/archives/libvir-list/2018-March/msg01541.html diff to v1: - Moved code to new file virdevmapper.c - Rename to virDevMapperGetTargets because this bug is not specific just to multipath rather than all device mapper targets - Reworked logging as suggested in review to v1 Michal Privoznik (3): util: Introduce virDevMapperGetTargets qemu: Handle device mapper targets properly news: Document device mapper fix docs/news.xml | 10 +++ libvirt.spec.in | 2 + src/libvirt_private.syms | 4 ++ src/qemu/qemu_cgroup.c | 42 ++++++++++++- src/qemu/qemu_domain.c | 64 +++++++++++++++++++ src/util/Makefile.inc.am | 2 + src/util/virdevmapper.c | 160 +++++++++++++++++++++++++++++++++++++++++++++++ src/util/virdevmapper.h | 32 ++++++++++ 8 files changed, 313 insertions(+), 3 deletions(-) create mode 100644 src/util/virdevmapper.c create mode 100644 src/util/virdevmapper.h -- 2.16.1

2 9

[libvirt] [PATCH 0/4] Introduce support for mediated devices hot plug
by Erik Skultety 28 Mar '18

28 Mar '18

Libvirt shouldn't forbid the operation as unsupported. In fact, from VFIO point of view, mdevs have supported hot plug since the beginning. Then it's up to the 3rd party vendor driver whether it can cope with this feature reliably or not. Erik Skultety (4): qemu: hotplug: Provide a string of a subsystem type instead of an int qemu: hotplug: Introduce hot plug support for mediated devices qemu: hotplug: Introduce hot unplug for mediated devices news: Update release news with mediated devices hot {plug,unplug} docs/news.xml | 14 +++++ src/qemu/qemu_hotplug.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 149 insertions(+), 1 deletion(-) -- 2.14.3

3 15

[libvirt] [[RFC] 0/8] Implement async QEMU event handling in libvirtd.
by Prerna Saxena 28 Mar '18

28 Mar '18

As noted in https://www.redhat.com/archives/libvir-list/2017-May/msg00016.html libvirt-QEMU driver handles all async events from the main loop. Each event handling needs the per-VM lock to make forward progress. In the case where an async event is received for the same VM which has an RPC running, the main loop is held up contending for the same lock. This impacts scalability, and should be addressed on priority. Note that libvirt does have a 2-step deferred handling for a few event categories, but (1) That is insufficient since blockign happens before the handler could disambiguate which one needs to be posted to this other queue. (2) There needs to be homogeniety. The current series builds a framework for recording and handling VM events. It initializes per-VM event queue, and a global event queue pointing to events from all the VMs. Event handling is staggered in 2 stages: - When an event is received, it is enqueued in the per-VM queue as well as the global queues. - The global queue is built into the QEMU Driver as a threadpool (currently with a single thread). - Enqueuing of a new event triggers the global event worker thread, which then attempts to take a lock for this event's VM. - If the lock is available, the event worker runs the function handling this event type. Once done, it dequeues this event from the global as well as per-VM queues. - If the lock is unavailable(ie taken by RPC thread), the event worker thread leaves this as-is and picks up the next event. - Once the RPC thread completes, it looks for events pertaining to the VM in the per-VM event queue. It then processes the events serially (holding the VM lock) until there are no more events remaining for this VM. At this point, the per-VM lock is relinquished. Patch Series status: Strictly RFC only. No compilation issues. I have not had a chance to (stress) test it after rebase to latest master. Note that documentation and test coverage is TBD, since a few open points remain. Known issues/ caveats: - RPC handling time will become non-deterministic. - An event will only be "notified" to a client once the RPC for same VM completes. - Needs careful consideration in all cases where a QMP event is used to "signal" an RPC thread, else will deadlock. Will be happy to drive more discussion in the community and completely implement it. Prerna Saxena (8): Introduce virObjectTrylock() QEMU Event handling: Introduce async event helpers in qemu_event.[ch] Setup global and per-VM event queues. Also initialize per-VM queues when libvirt reconnects to an existing VM. Events: Allow monitor to "enqueue" events to a queue. Also introduce a framework of handlers for each event type, that can be called when the handler is running an event. Events: Plumb event handling calls before a domain's APIs complete. Code refactor: Move helper functions of doCoreDump*, syncNicRxFilter*, and qemuOpenFile* to qemu_process.[ch] Fold back the 2-stage event implementation for a few events : Watchdog, Monitor EOF, Serial changed, Guest panic, Nic RX filter changed .. into single level. Initialize the per-VM event queues in context of domain init. src/Makefile.am | 1 + src/conf/domain_conf.h | 3 + src/libvirt_private.syms | 1 + src/qemu/qemu_conf.h | 4 + src/qemu/qemu_driver.c | 1710 +++++++---------------------------- src/qemu/qemu_event.c | 317 +++++++ src/qemu/qemu_event.h | 231 +++++ src/qemu/qemu_monitor.c | 592 ++++++++++-- src/qemu/qemu_monitor.h | 80 +- src/qemu/qemu_monitor_json.c | 291 +++--- src/qemu/qemu_process.c | 2031 ++++++++++++++++++++++++++++++++++-------- src/qemu/qemu_process.h | 88 ++ src/util/virobject.c | 26 + src/util/virobject.h | 4 + src/util/virthread.c | 5 + src/util/virthread.h | 1 + tests/qemumonitortestutils.c | 2 +- 17 files changed, 3411 insertions(+), 1976 deletions(-) create mode 100644 src/qemu/qemu_event.c create mode 100644 src/qemu/qemu_event.h -- 2.9.5

6 19

[libvirt] [dbus PATCH] domain: remove G_GNUC_UNUSED for used attributes
by Ján Tomko 28 Mar '18

28 Mar '18

A few functions use the G_GNUC_UNUSED marker for objectPath, even though it's passed to virtDBusDomainGetVirDomain later. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Also passes the build with clang 5.0.1, once that lock issue is fixed: connect.c:59:29: error: unused variable 'lock' [-Werror,-Wunused-variable] g_autoptr(GMutexLocker) lock = g_mutex_locker_new(&connect->lock); src/domain.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/domain.c b/src/domain.c index 3c09351..879366f 100644 --- a/src/domain.c +++ b/src/domain.c @@ -278,7 +278,7 @@ G_DEFINE_AUTOPTR_CLEANUP_FUNC(virDomainStatsRecordPtr, virDomainStatsRecordListF static void virtDBusDomainGetStats(GVariant *inArgs, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs, GUnixFDList **outFDs G_GNUC_UNUSED, @@ -313,7 +313,7 @@ virtDBusDomainGetStats(GVariant *inArgs, static void virtDBusDomainShutdown(GVariant *inArgs G_GNUC_UNUSED, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs G_GNUC_UNUSED, GUnixFDList **outFDs G_GNUC_UNUSED, @@ -336,7 +336,7 @@ virtDBusDomainShutdown(GVariant *inArgs G_GNUC_UNUSED, static void virtDBusDomainDestroy(GVariant *inArgs G_GNUC_UNUSED, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs G_GNUC_UNUSED, GUnixFDList **outFDs G_GNUC_UNUSED, @@ -383,7 +383,7 @@ virtDBusDomainReboot(GVariant *inArgs, static void virtDBusDomainReset(GVariant *inArgs, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs G_GNUC_UNUSED, GUnixFDList **outFDs G_GNUC_UNUSED, @@ -407,7 +407,7 @@ virtDBusDomainReset(GVariant *inArgs, static void virtDBusDomainCreate(GVariant *inArgs G_GNUC_UNUSED, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs G_GNUC_UNUSED, GUnixFDList **outFDs G_GNUC_UNUSED, @@ -430,7 +430,7 @@ virtDBusDomainCreate(GVariant *inArgs G_GNUC_UNUSED, static void virtDBusDomainUndefine(GVariant *inArgs G_GNUC_UNUSED, GUnixFDList *inFDs G_GNUC_UNUSED, - const gchar *objectPath G_GNUC_UNUSED, + const gchar *objectPath, gpointer userData, GVariant **outArgs G_GNUC_UNUSED, GUnixFDList **outFDs G_GNUC_UNUSED, -- 2.16.1

2 1

[libvirt] [jenkins-ci PATCH] Revert "local"
by Andrea Bolognani 28 Mar '18

28 Mar '18

This reverts commit c190e17fb8f689a0591dedded33d10cecafe3e20. As the original commit message so eloquently explains, the diff contains the tweaks I need for my local setup and it was, of course, never supposed to be pushed :/ Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed under the -ETOOEMBARRASSING rule. guests/files/ccache.conf | 2 +- guests/group_vars/all/install.yml | 6 +++--- guests/site.yml | 2 +- guests/tasks/users.yml | 18 ------------------ 4 files changed, 5 insertions(+), 23 deletions(-) diff --git a/guests/files/ccache.conf b/guests/files/ccache.conf index 18c7d97..48c3756 100644 --- a/guests/files/ccache.conf +++ b/guests/files/ccache.conf @@ -1 +1 @@ -max_size = 1G +max_size = 2G diff --git a/guests/group_vars/all/install.yml b/guests/group_vars/all/install.yml index 780f821..94b752f 100644 --- a/guests/group_vars/all/install.yml +++ b/guests/group_vars/all/install.yml @@ -4,8 +4,8 @@ install_virt_type: kvm install_arch: x86_64 install_machine: pc install_cpu_model: host-passthrough -install_vcpus: 4 -install_memory_size: 1 -install_disk_size: 10 +install_vcpus: 2 +install_memory_size: 2 +install_disk_size: 15 install_storage_pool: default install_network: default diff --git a/guests/site.yml b/guests/site.yml index dfe24bd..869291d 100644 --- a/guests/site.yml +++ b/guests/site.yml @@ -38,7 +38,7 @@ # Install build dependencies for each project - include: tasks/packages.yml with_items: - - libvirt + '{{ projects }}' loop_control: loop_var: project when: diff --git a/guests/tasks/users.yml b/guests/tasks/users.yml index e9840fb..1ecacee 100644 --- a/guests/tasks/users.yml +++ b/guests/tasks/users.yml @@ -82,21 +82,3 @@ owner: '{{ flavor }}' group: '{{ flavor }}' create: yes - -- name: '{{ flavor }}: Enable vi mode' - lineinfile: - path: /home/{{ flavor }}/.profile - line: 'set -o vi' - state: present - owner: '{{ flavor }}' - group: '{{ flavor }}' - create: yes - -- name: '{{ flavor }}: Enable vi mode' - lineinfile: - path: /home/{{ flavor }}/.bashrc - line: 'set -o vi' - state: present - owner: '{{ flavor }}' - group: '{{ flavor }}' - create: yes -- 2.14.3

3 5

[libvirt] [dbus PATCH 0/2] misc fixes
by Pavel Hrdina 27 Mar '18

27 Mar '18

2 4

[libvirt] [jenkins-ci PATCH 0/2] guests: Install and enable chrony
by Andrea Bolognani 27 Mar '18

27 Mar '18

Time travel is no longer allowed on these premises. Andrea Bolognani (2): guests: Move environment configuration steps together guests: Install and enable chrony guests/site.yml | 7 ++++--- guests/tasks/services.yml | 15 +++++++++++++++ guests/vars/mappings.yml | 3 +++ guests/vars/projects/base.yml | 1 + 4 files changed, 23 insertions(+), 3 deletions(-) create mode 100644 guests/tasks/services.yml -- 2.14.3

2 3

[libvirt] [PATCH v4 0/9] x86: Secure Encrypted Virtualization (AMD)
by Brijesh Singh 27 Mar '18

27 Mar '18

This patch series provides support for launching an encrypted guest using AMD's new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. At very high level the flow looks this: 1. mgmt tool calls virConnectGetDomainCapabilities. This returns an XML document that includes the following <feature> ... <sev supported='yes'> <cbitpos> </cbitpos> <reduced-phys-bits> </reduced-phys-bits> <pdh> </pdh> <cert-chain> </cert-chain> </feature> If <sev> is provided then we indicate that hypervisor is capable of launching SEV guest. 2. (optional) mgmt tool can provide the PDH and Cert-chain to guest owner in case if guest owner wish to establish a secure connection with SEV firmware to negotiate a key used for validating the measurement. 3. mgmt tool requests to start a guest calling virCreateXML(), passing VIR_DOMAIN_START_PAUSED. The xml would include <launch-security type='sev'> <cbitpos> </cbitpos> /* the value is same as what is obtained via virConnectGetDomainCapabilities() <reduced-phys-bits> </reduced-phys-bits> /* the value is same as what is obtained via virConnectGetDomainCapabilities() <dh-cert> .. </dh> /* guest owners diffie-hellman key */ (optional) <session> ..</session> /* guest owners session blob */ (optional) <policy> ..</policy> /* guest policy */ (optional) </launch-security> 4. Libvirt generate the QEMU cli arg to enable the SEV feature, a typical args looks like this: # $QEMU .. -machine memory-encryption=sev0 \ -object sev-guest,id=sev0,dh-cert-file=<file>.... 5. Libvirt generates lifecycle VIR_DOMAIN_EVENT_SUSPENDED_PAUSED event 6. mgmt tool gets the VIR_DOMAIN_EVENT_SUSPENDED_PAUSED and calls virDomainGetLaunchSecretInfo() to retrieve the measurement of encrypted memory. 7. (optional) mgmt tool can provide the measurement value to guest owner, which can validate the measurement and gives GO/NO-GO answer. If mgmt tool gets GO then it resumes the guest otherwise it calls destroy() to kill the guest. 8. mgmt tool resumes the guest TODO: * SEV guest require to use DMA apis for the virtio devices. In order to use the DMA apis the virtio devices must have this tag <driver iommu=on ats=on> It is a bit unclear to me where these changes need to go. Do we need to modify the libvirt to automatically add these when SEV is enabled or we ask mgmt tool to make sure that it creates XML with right tag to enable the DMA APIs for virtio devices. I am looking for some suggestions. Using these patches we have succesfully booted and tested a guest both with and without SEV enabled. SEV Firmware API spec is available at: https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf Changes since v3: * rename QEMU_CAPS_SEV -> QEMU_CAPS_SEV_GUEST * update caps_2.12.0.x86_64.replies to include query-sev-capabilities data Changes since v2: * make cbitpos, policy and reduced-phys-bits as unsigned int * update virDomainGetLaunchSecurityInfo to accept virTypedParameterPtr *params instead of virTypedParameterPtr params. Changes since v1: * rename <sev> -> <launch-security> for domain * add more information about policy and other fields in domaincaps.html * split the domain_conf support in two patches * add virDomainGetLaunchInfo() to retrieve the SEV measurement * extend virsh command to show the domain's launch security information * add test cases to validate newly added <launch-security> element * fix issues reported with 'make check' and 'make syntax-check' The complete git tree is available at: https://github.com/codomania/libvirt/tree/v3 Brijesh Singh (8): qemu: provide support to query the SEV capability qemu: introduce SEV feature in hypervisor capabilities conf: introduce launch-security element in domain qemu: add support to launch SEV guest libvirt: add new public API to get launch security info remote: implement the remote protocol for launch security qemu_driver: add support to launch security info virsh: implement new command for launch security Xiaogang Chen (1): tests: extend tests to include sev specific tag parsing docs/formatdomain.html.in | 120 +++++++++++++++++++++ docs/formatdomaincaps.html.in | 40 +++++++ docs/schemas/domaincaps.rng | 20 ++++ docs/schemas/domaincommon.rng | 39 +++++++ include/libvirt/libvirt-domain.h | 17 +++ src/conf/domain_capabilities.c | 20 ++++ src/conf/domain_capabilities.h | 14 +++ src/conf/domain_conf.c | 110 +++++++++++++++++++ src/conf/domain_conf.h | 26 +++++ src/driver-hypervisor.h | 7 ++ src/libvirt-domain.c | 48 +++++++++ src/libvirt_public.syms | 5 + src/qemu/qemu_capabilities.c | 40 +++++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_capspriv.h | 4 + src/qemu/qemu_command.c | 35 ++++++ src/qemu/qemu_driver.c | 66 ++++++++++++ src/qemu/qemu_monitor.c | 17 +++ src/qemu/qemu_monitor.h | 6 ++ src/qemu/qemu_monitor_json.c | 105 ++++++++++++++++++ src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 58 ++++++++++ src/remote/remote_daemon_dispatch.c | 47 ++++++++ src/remote/remote_driver.c | 42 +++++++- src/remote/remote_protocol.x | 20 +++- src/remote_protocol-structs | 11 ++ tests/genericxml2xmlindata/sev.xml | 20 ++++ tests/genericxml2xmloutdata/sev.xml | 22 ++++ tests/genericxml2xmltest.c | 2 + .../caps_2.12.0.x86_64.replies | 10 ++ tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 3 +- tests/qemuxml2argvdata/sev.args | 24 +++++ tests/qemuxml2argvdata/sev.xml | 35 ++++++ tests/qemuxml2argvtest.c | 2 + tests/qemuxml2xmloutdata/sev.xml | 39 +++++++ tests/qemuxml2xmltest.c | 2 + tools/virsh-domain.c | 84 +++++++++++++++ 37 files changed, 1163 insertions(+), 3 deletions(-) create mode 100644 tests/genericxml2xmlindata/sev.xml create mode 100644 tests/genericxml2xmloutdata/sev.xml create mode 100644 tests/qemuxml2argvdata/sev.args create mode 100644 tests/qemuxml2argvdata/sev.xml create mode 100644 tests/qemuxml2xmloutdata/sev.xml -- 2.7.4

1 9