[libvirt] [PATCH] remote: remove outdated comment about Solaris
by Daniel P. Berrangé
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
7 years
[libvirt] [PATCH v2 0/3] Introduce hot plug support for mediated devices
by Erik Skultety
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
7 years
[libvirt] [PATCH v2 0/3] Improve handling of multipath devices
by Michal Privoznik
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
7 years
[libvirt] [PATCH 0/4] Introduce support for mediated devices hot plug
by Erik Skultety
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
7 years
[libvirt] [[RFC] 0/8] Implement async QEMU event handling in libvirtd.
by Prerna Saxena
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
7 years
[libvirt] [dbus PATCH] domain: remove G_GNUC_UNUSED for used attributes
by Ján Tomko
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
7 years
[libvirt] [jenkins-ci PATCH] Revert "local"
by Andrea Bolognani
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
7 years
[libvirt] [dbus PATCH 0/2] misc fixes
by Pavel Hrdina
Pavel Hrdina (2):
Initialize struct using 0 instead of NULL
util: Introduce virtDBusUtilAutoLock
src/connect.c | 6 +++---
src/domain.c | 4 ++--
src/gdbus.c | 4 ++--
src/main.c | 2 +-
src/util.h | 2 ++
5 files changed, 10 insertions(+), 8 deletions(-)
--
2.14.3
7 years
[libvirt] [jenkins-ci PATCH 0/2] guests: Install and enable chrony
by Andrea Bolognani
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
7 years
[libvirt] [PATCH v4 0/9] x86: Secure Encrypted Virtualization (AMD)
by Brijesh Singh
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
7 years
