[libvirt] [PATCH 0/2] vnc: remove deprecated TLS related features
by Daniel P. Berrangé
Daniel P. Berrangé (2):
doc: switch to modern syntax for VNC TLS setup
vnc: remove support for deprecated tls, x509, x509verify options
qemu-deprecated.texi | 20 ----------
qemu-doc.texi | 20 +++++++---
qemu-options.hx | 43 ---------------------
ui/vnc.c | 91 --------------------------------------------
4 files changed, 15 insertions(+), 159 deletions(-)
--
2.17.1
5 years, 9 months
[libvirt] [PATCHv2 00/11] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher
Some architectures (S390) depend on QEMU to compute baseline CPU model and
expand a models feature set.
Interacting with QEMU requires starting the QEMU process and completing one or
more query-cpu-model-baseline QMP exchanges with QEMU in addition to a
query-cpu-model-expansion QMP exchange to expand all features in the model.
See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion
of QEMU aspects.
This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999
Version 2 address all issues raised by Collin as well as all other issues
identified with additional testing.
Chris Venteicher (11):
qemu_monitor_json: Introduce qemuMonitorCPUModelInfo / JSON conversion
qemu_monitor: Introduce qemuMonitorGetCPUModelBaseline
(query-cpu-model-baseline)
qemu_monitor: Indicate when CPUModelInfo props report migratablity
qemu_monitor: Introduce qemuMonitorCPUModelInfoInit and
qemuMonitorCPUModelInfoFreeContents
qemu_monitor: CPUModelExpansion on both model name and properties
qemu_monitor: Introduce qemuMonitorCPUModelInfoRemovePropByBoolValue
qemu_capabilities: Introduce virCPUDef / qemuMonitorCPUModelInfo
conversions
qemu_capabilities: QMPCommandPtr without maintaining shadow qmperr
qemu_capabilities: Persist QEMU instance over multiple QMP Cmds
qemu_capabilities: Introduce virQEMUCapsQMPBaselineCPUModel (baseline
using QEMU)
qemu_driver: BaselineHypervisorCPU supports S390 using QEMU/QMP
src/qemu/qemu_capabilities.c | 349 +++++++++++++++++++++++++++++------
src/qemu/qemu_capabilities.h | 33 ++++
src/qemu/qemu_driver.c | 74 +++++++-
src/qemu/qemu_monitor.c | 117 +++++++++++-
src/qemu/qemu_monitor.h | 21 ++-
src/qemu/qemu_monitor_json.c | 232 +++++++++++++++++++----
src/qemu/qemu_monitor_json.h | 14 +-
tests/cputest.c | 7 +-
8 files changed, 724 insertions(+), 123 deletions(-)
--
2.17.1
5 years, 9 months
[libvirt] [RFC PATCH 00/17] Add vhost-user-gpu support
by marcandre.lureau＠redhat.com
From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Hi,
This series of patches add support for running a virtio GPU in a
seperate process, using vhost-user.
The QEMU series "[PATCH v4 00/29] vhost-user for input & GPU" is still
under review, and will hopefully land in 3.1. There are several
benefits of running the GPU process in an external process, since Mesa
is rather heavy on the qemu main loop, and may block for a while or
crash. I observe x5 performance improvements with Unigine Heaven 4
benchmark.
The external GPU process is started with one end of the vhost-user
socket pair, the other end is given to a QEMU chardev. It is also
added to the emulator cgroup to restrict its CPU usage.
vhost-user requires shared VM memory. A few preliminary patches ease
and improve shared memory setup, when no explicit domain NUMA
configuration is given. Also, if there is no need for file-backed
memory, teach libvirt to make use of memfd memory backend, which has
better security guarantees and is easier to setup.
Review welcome!
Marc-André Lureau (17):
qemu: setup shared memory without explicit numa configuration
qemu: add memory-backend-memfd capability check
qemu: use memory-backend-memfd if possible
qemu: add vhost-user-gpu capabilities
domain: add "vhost-user" video type
qemu: fill the vhost-user video type capability
qemu: check that qemu is vhost-user-vga capable
qemu: vhost-user is valid as non-primary video device
qemu: validate vhost-user video model
qemu: add qemuSecurityStartVhostUserGPU helper
qemu: add vhost-user-gpu helper unit
qemu: restrict 'virgl=' option to 'virtio' video type
qemu: set default address type on vhost-user video model
qemu: start/stop the vhost-user-gpu external device
qemu: build vhost-user-backend for vhost-user-gpu
qemu: build vhost-user-gpu video device arguments
tests: add vhost-user-gpu xml2argv tests
docs/formatdomain.html.in | 5 +-
docs/schemas/domaincommon.rng | 1 +
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 4 +-
src/conf/domain_conf.h | 1 +
src/qemu/Makefile.inc.am | 2 +
src/qemu/qemu_capabilities.c | 10 +
src/qemu/qemu_capabilities.h | 5 +
src/qemu/qemu_command.c | 191 ++++++++---
src/qemu/qemu_domain.c | 8 +-
src/qemu/qemu_domain_address.c | 4 +-
src/qemu/qemu_extdevice.c | 47 ++-
src/qemu/qemu_process.c | 6 +-
src/qemu/qemu_security.c | 48 +++
src/qemu/qemu_security.h | 6 +
src/qemu/qemu_vhost_user_gpu.c | 318 ++++++++++++++++++
src/qemu/qemu_vhost_user_gpu.h | 48 +++
tests/domaincapsschemadata/full.xml | 1 +
.../caps_2.12.0.aarch64.xml | 1 +
.../caps_2.12.0.ppc64.xml | 1 +
.../caps_2.12.0.s390x.xml | 1 +
.../caps_2.12.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 +
.../caps_3.0.0.x86_64.xml | 1 +
.../fd-memory-no-numa-topology.args | 4 +
tests/qemuxml2argvdata/memfd.args | 28 ++
tests/qemuxml2argvdata/memfd.xml | 32 ++
.../vhost-user-gpu-secondary.args | 34 ++
.../vhost-user-gpu-secondary.xml | 38 +++
tests/qemuxml2argvdata/vhost-user-vga.args | 31 ++
tests/qemuxml2argvdata/vhost-user-vga.xml | 35 ++
tests/qemuxml2argvtest.c | 14 +
32 files changed, 877 insertions(+), 51 deletions(-)
create mode 100644 src/qemu/qemu_vhost_user_gpu.c
create mode 100644 src/qemu/qemu_vhost_user_gpu.h
create mode 100644 tests/qemuxml2argvdata/memfd.args
create mode 100644 tests/qemuxml2argvdata/memfd.xml
create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.args
create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.xml
create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.args
create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.xml
--
2.18.0.129.ge3331758f1
5 years, 9 months
[libvirt] [PATCH v3 0/3] Don't touch user data from tests
by Michal Privoznik
v3 of:
https://www.redhat.com/archives/libvir-list/2018-July/msg00747.html
diff to v2:
- pushed some already ACKed patches
- dropped controversial line from 1/3 that turned off error reporting
Michal Prívozník (3):
qemuxml2argvtest: Set more fake drivers
check-file-access: Allow specifying action
virtestmock: Track action
tests/check-file-access.pl | 32 +++++++++++++++++++++++++++-----
tests/file_access_whitelist.txt | 15 ++++++++++-----
tests/qemuxml2argvtest.c | 4 ++++
tests/virtestmock.c | 39 ++++++++++++++++++++++-----------------
4 files changed, 63 insertions(+), 27 deletions(-)
--
2.16.4
5 years, 9 months
[libvirt] [dbus PATCH 0/4] Fix 'make check' with libvirt 3.0.0
by Andrea Bolognani
Andrea Bolognani (4):
tests: Drop pytest.mark.usefixtures from test_nodedev
tests: Move some test cases to test_nodedev
tests: Don't open-code node_device_create()
tests: Make node_device_create() work with libvirt 3.0.0
tests/libvirttest.py | 17 ++++++++++++++++-
tests/test_connect.py | 27 ---------------------------
tests/test_nodedev.py | 26 +++++++++++++++++++++++++-
tests/xmldata.py | 2 +-
4 files changed, 42 insertions(+), 30 deletions(-)
--
2.17.1
5 years, 9 months
[libvirt] [PATCH v2] libvirt_iohelper: record the libvirt_iohelper's error message at virFileWrapperFdFree
by xinhua.Cao
Currently iohelper's error log is recorded in virFileWrapperFdClose.
In qemuDomainSaveMemory, it usually fails at qemuMigrationSrcToFile,
and then goto cleanup, so the iohelper error log is not recorded,
and so is the another placement. We now record the error log of
iohelper by move it to the virFileWrapperFdFree record.
And for the virCommandWait() - we should call virCommandAbort() in
virFileWrapperFdFree() to make sure no process is left behind. If
virCommandWait() is called then virCommandAbort() is a NO-OP. If it
isn't, then Abort() will kill iohelper. Thanks for Michal for this
advice
Signed-off-by: xinhua.Cao <caoxinhua(a)huawei.com>
---
src/util/virfile.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 1faeebb..590fc0e 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -330,9 +330,6 @@ virFileWrapperFdClose(virFileWrapperFdPtr wfd)
return 0;
ret = virCommandWait(wfd->cmd, NULL);
- if (wfd->err_msg && *wfd->err_msg)
- VIR_WARN("iohelper reports: %s", wfd->err_msg);
-
return ret;
}
@@ -351,6 +348,10 @@ virFileWrapperFdFree(virFileWrapperFdPtr wfd)
if (!wfd)
return;
+ if (wfd->err_msg && *wfd->err_msg)
+ VIR_WARN("iohelper reports: %s", wfd->err_msg);
+
+ virCommandAbort(wfd->cmd);
VIR_FREE(wfd->err_msg);
virCommandFree(wfd->cmd);
--
2.8.3
5 years, 9 months
[libvirt] [PATCH v2 RESEND 00/17] Introduce RDT memory bandwidth allocation support
by bing.niu＠intel.com
From: Bing Niu <bing.niu(a)intel.com>
This series is to introduce RDT memory bandwidth allocation support by extending
current virresctrl implementation.
The Memory Bandwidth Allocation (MBA) feature provides indirect and approximate
control over memory bandwidth available per-core. This feature provides a method to
control applications which may be over-utilizing bandwidth relative to their priority
in environments such as the data-center. The details can be found in Intel's SDM 17.19.7.
Kernel supports MBA through resctrl file system same as CAT. Each resctrl group have a
MB parameter to control how much memory bandwidth it can utilize in unit of percentage.
In this series, MBA is enabled by enhancing existing virresctrl implementation. The
policy employed for MBA is similar with CAT: The sum of each MBA group's bandwidth
dose not exceed 100%.
The enhancement of virresctrl include two main parts:
Part 1: Add two new structures virResctrlInfoMemMB and virResctrlAllocMemBW for collecting
host system MBA capability and domain memory bandwidth allocation. Those two
structures are the extension of existing virResctrlInfo and virResctrlAlloc. With
them, virresctrl framework can support MBA and CAT concurrently. Each virResctrlAlloc
represent a resource allocation including CAT, or MBA, or CAT&MBA. The policy of MBA is
that: total memory bandwidth of each resctrl group, created by virresctrl, does not
exceed to 100%.
Part 2: On XML part, add new elements to host capabilities query and domain allocation to support
memory bandwidth allocation.
---------------------------------------------------------------------------------------------
For host capabilities XML, new XML format like below example,
<host>
.....
<memory_bandwidth>
<node id='0' cpus='0-19'>
<control granularity='10' min ='10' maxAllocs='8'/>
</node>
</memory_bandwidth>
</host>
granularity --- memory bandwidth granularity
min --- minimum memory bandwidth allowed
maxAllocs --- maximum concurrent memory bandwidth allocation allowed.
---------------------------------------------------------------------------------------------
For domain XML, new format as below example
<domain type='kvm' id='2'>
......
<cputune>
......
<shares>1024</shares>
<memorytune vcpus='0-1'>
<node id='0' bandwidth='20'/>
</memorytune>
</cputune>
......
</domain>
id --- node where memory bandwidth allocation will happen
bandwidth --- bandwidth allocated in percentage
----------------------------------------------------------------------------------------------
With this extension of the virresctrl, the overall working follow of CAT and MBA is described by below
picture. XML parser will aggregate MBA and CAT configuration and represents it in one virresctrl object.
The methods of virresctrl class will manipulate resctrl interface to allocate corresponding resources.
<memorytune cpus='0-3'>
+---------+
| <cachetune vcpus='0-3'>
XML | +
parser +-----------+
|
|
+------------------------------+
|
|
internal object +------v--------------+
virResctrlAlloc | backing object |
+------+--------------+
|
|
+------------------------------+
|
+--v-------+
| |
| schemata |
/sys/fs/resctrl | tasks |
| . |
| . |
| |
+----------+
---------------------------------------------------------------------
previous versions and discussion can be found at
v1: https://www.redhat.com/archives/libvir-list/2018-July/msg01144.html
RFC v2: https://www.redhat.com/archives/libvir-list/2018-June/msg01268.html
RFC v1: https://www.redhat.com/archives/libvir-list/2018-May/msg02101.html
Changelog:
v1 -> this: John's comment: 1. Split calculation of number of memory bandwidth control
to one patch.
2. Split virResctrlAllocMemBW relating methods to 5 patch, each
provides one kind of function, eg: schemata processing, memory
bandwidth calculation.....
3. Use resctrl to replace cachetune in domain conf.
4. Split refactor virDomainCachetuneDefParse into 3 patches. And
adjust some logic, eg: use %s format error log, renaming
functions.....
5. Complete doc description. eg: update cachetune part about vcpus
overlapping with memorytune, update libvirt version info for memory
bandwidth control availability.
6. Some coding style fix.
RFC_v2->v1: John's comment: 1. use name MemBW to replace MB for a more clear description.
2. split rename patch and put refactor function part separately.
3. split virResctrlInfoMemMB and virResctrlAllocMemBW to different
patches.
4. add docs/schemas/*.rng for XML related patches.
5. some cleanup for coding conventions.
RFC_ v1->RFC_v2:
Jano's comment: 1. put renaming parts into separated patches.
2. set the initial return value as -1.
3. using full name in structure definition.
4. do not use VIR_CACHE_TYPE_LAST for memory bandwidth allocation formatting.
Pavel's comment: 1. add host capabilities XML for memory bandwidth allocation.
2. do not mix use cachetune section in XML for memory bandwidth allocation in
domain XML. define a dedicated one for memory bandwidth allocation.
Bing Niu (17):
util: Rename some functions of virresctrl
util: Refactor virResctrlGetInfo in virresctrl
util: Refactor virResctrlAllocFormat of virresctrl
util: Add MBA capability information query to resctrl
util: Add MBA check to virResctrlInfoGetCache
util: Add MBA allocation to virresctrl
util: Add MBA schemata parse and format methods
util: Add support to calculate MBA utilization
util: Introduce virResctrlAllocForeachMemory
util: Introduce virResctrlAllocSetMemoryBandwidth
conf: Rename cachetune to resctrl
conf: Factor out vcpus parsing part from virDomainCachetuneDefParse
conf: Factor out vcpus overlapping from virDomainCachetuneDefParse
conf: Factor out virDomainResctrlDef update from
virDomainCachetuneDefParse
conf: Add support for memorytune XML processing for resctrl MBA
conf: Add return value check to virResctrlAllocForeachCache
conf: Add memory bandwidth allocation capability of host
docs/formatdomain.html.in | 39 +-
docs/schemas/capability.rng | 33 ++
docs/schemas/domaincommon.rng | 17 +
src/conf/capabilities.c | 107 ++++
src/conf/capabilities.h | 11 +
src/conf/domain_conf.c | 428 ++++++++++++---
src/conf/domain_conf.h | 10 +-
src/libvirt_private.syms | 6 +-
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_process.c | 18 +-
src/util/virresctrl.c | 611 +++++++++++++++++++--
src/util/virresctrl.h | 55 +-
.../memorytune-colliding-allocs.xml | 30 +
.../memorytune-colliding-cachetune.xml | 32 ++
tests/genericxml2xmlindata/memorytune.xml | 33 ++
tests/genericxml2xmltest.c | 5 +
.../linux-resctrl/resctrl/info/MB/bandwidth_gran | 1 +
.../linux-resctrl/resctrl/info/MB/min_bandwidth | 1 +
.../linux-resctrl/resctrl/info/MB/num_closids | 1 +
tests/vircaps2xmldata/vircaps-x86_64-resctrl.xml | 8 +
tests/virresctrldata/resctrl.schemata | 1 +
21 files changed, 1280 insertions(+), 169 deletions(-)
create mode 100644 tests/genericxml2xmlindata/memorytune-colliding-allocs.xml
create mode 100644 tests/genericxml2xmlindata/memorytune-colliding-cachetune.xml
create mode 100644 tests/genericxml2xmlindata/memorytune.xml
create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/bandwidth_gran
create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/min_bandwidth
create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/num_closids
--
2.7.4
5 years, 9 months
[libvirt] [PATCH] spec: Use %make_install
by Cole Robinson
It's on RHEL7, saves a bit of typing, and lets us drop the comment
Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
---
There's also a %make_build macro which handles smp_mflags, but it uses
make -O which makes build output noisier at least
libvirt.spec.in | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 4113579e47..01f4e07b1c 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1255,10 +1255,7 @@ rm -fr %{buildroot}
export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec)
-# Avoid using makeinstall macro as it changes prefixes rather than setting
-# DESTDIR. Newer make_install macro would be better but it's not available
-# on RHEL 5, thus we need to expand it here.
-make %{?_smp_mflags} install DESTDIR=%{?buildroot} SYSTEMD_UNIT_DIR=%{_unitdir} V=1
+%make_install %{?_smp_mflags} SYSTEMD_UNIT_DIR=%{_unitdir} V=1
make %{?_smp_mflags} -C examples distclean V=1
--
2.17.1
5 years, 9 months
Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
by Alex Williamson
On Mon, 9 Apr 2018 12:35:10 +0200
Gerd Hoffmann <kraxel(a)redhat.com> wrote:
> This little series adds three drivers, for demo-ing and testing vfio
> display interface code. There is one mdev device for each interface
> type (mdpy.ko for region and mbochs.ko for dmabuf).
Erik Skultety brought up a good question today regarding how libvirt is
meant to handle these different flavors of display interfaces and
knowing whether a given mdev device has display support at all. It
seems that we cannot simply use the default display=auto because
libvirt needs to specifically configure gl support for a dmabuf type
interface versus not having such a requirement for a region interface,
perhaps even removing the emulated graphics in some cases (though I
don't think we have boot graphics through either solution yet).
Additionally, GVT-g seems to need the x-igd-opregion support
enabled(?), which is a non-starter for libvirt as it's an experimental
option!
Currently the only way to determine display support is through the
VFIO_DEVICE_QUERY_GFX_PLANE ioctl, but for libvirt to probe that on
their own they'd need to get to the point where they could open the
vfio device and perform the ioctl. That means opening a vfio
container, adding the group, setting the iommu type, and getting the
device. I was initially a bit appalled at asking libvirt to do that,
but the alternative is to put this information in sysfs, but doing that
we risk that we need to describe every nuance of the mdev device
through sysfs and it becomes a dumping ground for every possible
feature an mdev device might have.
So I was ready to return and suggest that maybe libvirt should probe
the device to know about these ancillary configuration details, but
then I remembered that both mdev vGPU vendors had external dependencies
to even allow probing the device. KVMGT will fail to open the device
if it's not associated with an instance of KVM and NVIDIA vGPU, I
believe, will fail if the vGPU manager process cannot find the QEMU
instance to extract the VM UUID. (Both of these were bad ideas)
Therefore, how can libvirt know if a given mdev device supports a
display and which type of display it supports, and potentially which
vendor specific options might be required to further enable that
display (if they weren't experimental)? A terrible solution would be
that libvirt hard codes that NVIDIA works with regions and Intel works
with dmabufs, but even then there's a backwards and forwards
compatibility problem, that libvirt needs to support older kernels and
drivers where display support is not present and newer drivers where
perhaps Intel is now doing regions and NVIDIA is supporting dmabuf, so
it cannot simply be assumed based on the vendor. The only solution I see
down that path would be identifying specific {vendor,type} pairs that
support a predefined display type, but that's just absurd to think that
vendors would rev their mdev types to expose this and that libvirt
would keep a database mapping types to features. We also have the name
and description attributes, but these are currently free form, so
libvirt rightfully ignores them entirely. I don't know if we could
create a defined feature string within those free form strings.
Otherwise, it seems we have no choice but to dive into the pool of
exposing such features via sysfs and we'll need to be vigilant of
feature creep or vendor specific features (ex. we're not adding a
feature to indicate an opregion requirement). How should we do this?
Perhaps a bar we can set is that if a feature cannot be discovered
through a standard vfio API, then it is not suitable for this sysfs
API. Such things can be described via our existing mdev vendor
specific attribute interface.
We currently have this sysfs interface:
mdev_supported_types/
|-- $VENDOR_TYPE
| |-- available_instances
| |-- create
| |-- description
| |-- device_api
| |-- devices
| `-- name
ioctls for vfio devices which only provide information include:
VFIO_DEVICE_GET_INFO
VFIO_DEVICE_GET_REGION_INFO
VFIO_DEVICE_GET_IRQ_INFO
VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
VFIO_DEVICE_QUERY_GFX_PLANE
We don't need to support all of these initially, but here's a starting
idea for what this may look like in sysfs:
$VENDOR_TYPE/
|-- available_instances
|-- create
|-- description
|-- device_api
|-- devices
|-- name
`-- vfio-pci
`-- device
|-- gfx_plane
| |-- dmabuf
| `-- region
|-- irqs
| |-- 0
| | |-- count
| | `-- flags
| `-- 1
| |-- count
| `-- flags
`-- regions
|-- 0
| |-- flags
| |-- offset
| `-- size
`-- 3
|-- flags
|-- offset
`-- size
The existing device_api file reports "vfio-pci", so we base the device
API info in a directory named vfio-pci. We're specifically exposing
device information, so we have a device directory. We have a GFX_PLANE
query ioctl, so we have a gfx_plane sub-directory. I imagine the
dmabuf and region files here expose either Y/N or 1/0. I continue on
the example with how we might expose irqs and regions, but even with
regions we can bury down into how is sparse mmap exposed, how are
device specific regions described, etc. Filling this in to completion
without a specific userspace need to expose the information is just an
exercise in bloating the kernel.
That almost begins to look reasonable, but then we can only expose this
for mdev devices, what if we were to hack a back door into a directly
assigned GPU that tracks the location of active display in the
framebuffer and implement the GFX_PLANE interface for that? We have no
sysfs representation for either the template or the actual device for
anything other than mdev. This inconsistency with physically assigned
devices has been one of my arguments against enhancing mdev sysfs.
Thanks to anyone still reading this. Ideas how we might help libvirt
fill this information void so that they can actually configure a VM
with a display device? Thanks,
Alex
5 years, 9 months
[libvirt] [PATCH libvirt v2 0/9] Fix virConnectRegisterCloseCallback and get rid of global variables
by Marc Hartmayer
The first part of this patch series fixes the behavior of
virConnectRegisterCloseCallback and converts the testDriver to
virObjectLockable.
The subsequent patches remove the need to have the global variables
'qemuProgram' and 'remoteProgram' in libvirtd.[ch]. They only work in
combination with the fixed behavior of virConnectRegisterCloseCallback.
Changelog:
+ v1->v2:
- Removed accepted patches
- Removed NACKed patches
- Added r-b to patch 5
- Worked in comments
- Rebased
- Added patches 7-9
Marc Hartmayer (9):
virConnectRegisterCloseCallback: Cleanup 'opaque' if there is no
connectRegisterCloseCallback
test: Convert testDriver to virObjectLockable
remote: Add the information which program has to be used to
daemonClientEventCallback
remote: Use domainClientEventCallbacks for
remoteReplayConnectionClosedEvent
rpc: Introduce virNetServerGetProgramLocked helper function
remote/rpc: Use virNetServerGetProgram() to determine the program
rpc: use the return value of virObjectRef directly
remote: remove ATTRIBUTE_UNUSED when attribute is actually used
remote: shrink the critical sections
src/libvirt-host.c | 10 +-
src/libvirt_remote.syms | 1 +
src/remote/remote_daemon.c | 4 +-
src/remote/remote_daemon.h | 3 -
src/remote/remote_daemon_dispatch.c | 264 +++++++++++++++++++++++-------------
src/rpc/gendispatch.pl | 6 +
src/rpc/virnetserver.c | 57 ++++++--
src/rpc/virnetserver.h | 2 +
src/test/test_driver.c | 200 ++++++++++++---------------
9 files changed, 328 insertions(+), 219 deletions(-)
--
2.13.4
5 years, 9 months
