[libvirt] [PATCHv3 0/7] Finish the conversion to virConfGetValue* functions
by Fabiano Fidêncio
This patchset finishes the conversion to virConfGetValue* functions,
started by Daniel Berrange a few months ago.
Please, mind that although we could make virConfGetValue* functions more
generic in order to support numbers and booleans as strings, that
doesn't seem the safest path to take. The side-effect of this is that we
will have to live with some specific code doing that as part of vmx and
xen_common.
Once this patchset gets merged,
https://wiki.libvirt.org/page/BiteSizedTasks#Finish_conversion_to_virConf...
can be removed.
- Changes since v1:
All the "values" from virConfGetValueString() are freed
- Changes since v2:
All comments from Ján Tomko have been addressed;
A few leaks were (possibly) found and they're addressed in the last
patch of the series;
Fabiano Fidêncio (7):
xen_xm: Split the per-disk logic from xenParseXMDisk()
xen_vm: convert to typesafe virConf accessors
vmx: convert to typesafe virConf accessors
xen_common: Split per-PCI logic from xenParsePCI()
xen_common: Split per-Vfi logic from xenParseVif()
xen_common: convert to typesafe virConf acessors
xen_common: Fix a few memory leaks
src/vmx/vmx.c | 194 +++++--------
src/xenconfig/xen_common.c | 701 +++++++++++++++++++++++----------------------
src/xenconfig/xen_xm.c | 306 ++++++++++----------
3 files changed, 595 insertions(+), 606 deletions(-)
--
2.14.3
6 years, 6 months
[libvirt] [PATCH 00/12] Various apparmor related changes (part )
by Christian Ehrhardt
Hi,
this is a continuation of the ongoing effort to feed back Ubuntu apparmor
Delta on libvirt to the community (or to sort out remaining todos or to keep
them distro specific).
In that it is a follow on to:
- https://www.redhat.com/archives/libvir-list/2017-May/msg00630.html
- https://www.redhat.com/archives/libvir-list/2017-May/msg00887.html
I punted those we had discussions on and decided to rework in the last rounds
out of the submission.
But in exchange pulled in some more changes we had that are now ready for
discussion. That way I prepared the next set of 12 changes which I hereby
submit for your consideration into 3.11.
Christian Ehrhardt (3):
apparmor, libvirt-qemu: add default pki path of lbvirt-spice
apparmor, libvirt-qemu: add generic base vfio device
apparmor, libvirt-qemu: qemu won't call qemu-nbd
Jamie Strandboge (5):
apparmor, libvirt-qemu: Allow read access to sysfs system info
apparmor, libvirt-qemu: Allow qemu-block-extra libraries
apparmor, libvirtd: Allow ixr to /var/lib/libvirt/virtd*
apparmor, virt-aa-helper: Allow access to ecryptfs files
apparmor, virt-aa-helper: Allow access to /sys/bus/usb/devices
Serge Hallyn (3):
apparmor, libvirt-qemu: Allow use of sgabios
apparmor, libvirt-qemu: Allow read access to max_mem_regions
apparmor, libvirt-qemu: Allow access to hugepage mounts
Stefan Bader (1):
apparmor, libvirt-qemu: Silence lttng related deny messages
examples/apparmor/libvirt-qemu | 26 +++++++++++++++++++++++-
examples/apparmor/usr.lib.libvirt.virt-aa-helper | 6 ++++++
examples/apparmor/usr.sbin.libvirtd | 4 ++++
3 files changed, 35 insertions(+), 1 deletion(-)
--
2.7.4
6 years, 6 months
[libvirt] [RFC PATCH 0/7] Enable vfio-pci 'property' for mediated devices
by Erik Skultety
Since QEMU 2.12 there's a new vfio-pci device property 'display' with values
on/off/auto. This special kind of display allows using a mediated device which
is a VGA compatible device for a display output.
There are 2 different implementations of how the device output is handled,
referred to as dmabuf and vfio region mapping (currently NVIDIA uses the latter,
while Intel relies on the former). From libvirt's perspective the important
difference is that dmabuf requires OpenGL support whereas vfio regions don't
(it will of course work even with OpenGL enabled). There's a catch though -
because of several constraints in the vendor drivers (as discussed here [1]),
there currently isn't a reasonable way for libvirt (other than spawning a dummy
QEMU instance) to probe such mediated devices for the display mode they use.
This the nr.1 reason why libvirt is not going to support the value 'auto' with
QEMU and will default to 'off' instead in all cases to stay safe the least and
therefore is going to rely on users being able to configure this properly
otherwise they'll get an error.
Once there's a way for libvirt to probe the nature of the display-capable
mediated devices, we can consider adding support for 'auto' value meaning that
libvirt is going to take care of adding an appropriate Spice/VNC graphics
device depending on the system if these are missing in the config, otherwise
the user's choice is always favoured.
TL;DR:
- we have a new attribute value for vfio-pci mediated devices called 'display'
-> devices can now format this new 'display=on/off' property to the cmdline
- if user enables the vfio display (display=on) but doesn't enable OpenGL for
Spice, we automatically assume the usage of '-display egl-headless'
(uses local drm nodes) which works both for Spice and VNC
-> if OpenGL is enabled, then '-display egl-headless' is not necessary
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1475770
[1] https://www.redhat.com/archives/libvir-list/2018-May/msg00243.html
Erik Skultety (7):
conf: Remove a redundant model/address-type check in mdev post parse
qemu: command: Move graphics iteration to its own function
conf: Introduce virDomainDefHasSpiceGL helper
conf: Introduce new <hostdev> attribute 'display'
qemu: caps: Add vfio-pci.display capability
qemu: domain: Set default vfio-pci display value depending on
capability
qemu: command: Enable formatting vfio-pci.display option onto cmdline
docs/formatdomain.html.in | 16 ++++-
docs/schemas/domaincommon.rng | 5 ++
src/conf/domain_conf.c | 56 +++++++++++----
src/conf/domain_conf.h | 4 ++
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 84 +++++++++++++++-------
src/qemu/qemu_domain.c | 75 +++++++++++++++++++
tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 +
.../hostdev-mdev-display-missing-graphics.xml | 35 +++++++++
.../hostdev-mdev-display-spice-no-opengl.args | 32 +++++++++
.../hostdev-mdev-display-spice-no-opengl.xml | 41 +++++++++++
.../hostdev-mdev-display-spice-opengl.args | 31 ++++++++
.../hostdev-mdev-display-spice-opengl.xml | 41 +++++++++++
.../qemuxml2argvdata/hostdev-mdev-display-vnc.args | 32 +++++++++
.../qemuxml2argvdata/hostdev-mdev-display-vnc.xml | 39 ++++++++++
tests/qemuxml2argvtest.c | 23 ++++++
.../hostdev-mdev-display-spice-no-opengl.xml | 47 ++++++++++++
.../hostdev-mdev-display-spice-opengl.xml | 48 +++++++++++++
.../hostdev-mdev-display-vnc.xml | 47 ++++++++++++
tests/qemuxml2xmltest.c | 3 +
25 files changed, 626 insertions(+), 41 deletions(-)
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-missing-graphics.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-no-opengl.args
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-no-opengl.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.args
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.args
create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-spice-no-opengl.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-spice-opengl.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-vnc.xml
--
2.14.3
6 years, 6 months
[libvirt] [RFC PATCH 0/2] 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 parts:
Patch 1: Add two new structure virResctrlInfoMB and virResctrlAllocMB for collecting
host system MBA capability and domain memory bandwidth allocation.
Patch 2: On frontend XML parsing, add new element "llc" in cachetune section for
MBA allocation.
Bing Niu (2):
util: Add memory bandwidth support to resctrl
conf: Extend cputune/cachetune to support memory bandwidth allocation
src/conf/domain_conf.c | 86 +++++++++-
src/util/virresctrl.c | 422 ++++++++++++++++++++++++++++++++++++++++++++++---
src/util/virresctrl.h | 5 +
3 files changed, 487 insertions(+), 26 deletions(-)
--
2.7.4
6 years, 6 months
[libvirt] [PATCH v2 0/2] bhyve: add CPU topology support
by Roman Bogorodskiy
Changes since v1:
- Added a check that nvcpus == sockets * cores * threads and
a test for that.
Roman Bogorodskiy (2):
bhyve: add CPU topology support
docs: bhyve: document guest CPU topology feature
docs/drvbhyve.html.in | 16 ++++++++++++
docs/news.xml | 9 +++++++
src/bhyve/bhyve_capabilities.c | 7 +++--
src/bhyve/bhyve_capabilities.h | 1 +
src/bhyve/bhyve_command.c | 26 ++++++++++++++++++-
...yvexml2argv-cputopology-nvcpu-mismatch.xml | 26 +++++++++++++++++++
.../bhyvexml2argv-cputopology.args | 9 +++++++
.../bhyvexml2argv-cputopology.ldargs | 3 +++
.../bhyvexml2argv-cputopology.xml | 26 +++++++++++++++++++
tests/bhyvexml2argvtest.c | 8 +++++-
10 files changed, 127 insertions(+), 4 deletions(-)
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology-nvcpu-mismatch.xml
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.args
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.ldargs
create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.xml
--
2.17.0
6 years, 6 months
[libvirt] [dbus PATCH 0/8] NWFilter APIs
by Katerina Koukiou
Katerina Koukiou (8):
Introduce NWFilter Interface
Implement ListNWFilters method for Connect Interface
Implement NWFilterDefineXML method for Connect Interface
Implement Name property for NWFilter Interface
Implement UUID property for NWFilter Interface
Implement GetXMLDesc method for NWFilter Interface
Implement NWFilterLookupByName method for Connect Interface
Implement NWFilterLookupByUUID method for Connect Interface
data/Makefile.am | 1 +
data/org.libvirt.Connect.xml | 24 +++++++
data/org.libvirt.NWFilter.xml | 23 +++++++
src/Makefile.am | 1 +
src/connect.c | 131 +++++++++++++++++++++++++++++++++++
src/connect.h | 1 +
src/nwfilter.c | 157 ++++++++++++++++++++++++++++++++++++++++++
src/nwfilter.h | 9 +++
src/util.c | 32 +++++++++
src/util.h | 15 ++++
10 files changed, 394 insertions(+)
create mode 100644 data/org.libvirt.NWFilter.xml
create mode 100644 src/nwfilter.c
create mode 100644 src/nwfilter.h
--
2.15.0
6 years, 6 months
[libvirt] [PATCH 00/13] PCI passthrough support on s390
by Xiao Feng Ren
The PCI representation in QEMU has recently been extended for S390
allowing configuration of zPCI attributes like uid (user-defined
identifier) and fid (PCI function identifier).
The details can be found here:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
To support the new zPCI feature of the S390 platform, two new XML
attributes, @uid and @fid, are introduced for device addresses of type
'pci', i.e.:
<hostdev mode='subsystem' type='pci'>
<driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'
uid='0x0003' fid='0x00000027'/>
</hostdev>
uid and fid are optional attributes. If they are defined by the user,
unique values within the guest domain must be used. If they are not
specified and the architecture requires them, they are automatically
generated with non-conflicting values.
Current implementation is the most seamless one for the user as it
unites the address specific data of a PCI device on one XML element.
It could accommodate both specifying our special parameters (uid and fid)
and re-using standard statements (domain, bus, slot and function) for
PCI devices. User can still specify bus/slot/function for the virtualized
PCI devices in the XML.
Thus uid/fid act as an extension to the PCI address and are stored in
a new structure 'virZPCIDeviceAddress' which is a member of common PCI
Address structure. Additionally, two hashtables are used for assignment
and reservation of uid/fid.
In support of extending the PCI address, a new PCI address extension flag is
introduced. This extension flag allows is not only dedicated for the S390
platform but also other architectures needing certain extensions to PCI
address space.
Yi Min Zhao (13):
conf: Add definitions for 'uid' and 'fid' PCI address attributes
qemu: Introduce zPCI capability
conf: Introduce a new PCI address extension flag
qemu: Enable PCI multi bus for S390 guests
qemu: Auto add pci-root for s390/s390x guests
qemu: Generate and use zPCI device in QEMU command line
qemu: Add hotpluging support for PCI devices on S390 guests
conf: Introduce parser, formatter for uid and fid
conf: Introduce address caching for PCI extensions
conf: Allocate/release 'uid' and 'fid' in PCI address
tests: Add new tests for zPCI
docs: Add 'uid' and 'fid' information
news: Update news for PCI address extension attributes
docs/formatdomain.html.in | 9 +-
docs/news.xml | 11 +
docs/schemas/basictypes.rng | 28 ++
docs/schemas/domaincommon.rng | 1 +
src/conf/device_conf.c | 74 +++++
src/conf/device_conf.h | 1 +
src/conf/domain_addr.c | 346 +++++++++++++++++++++
src/conf/domain_addr.h | 29 ++
src/conf/domain_conf.c | 4 +
src/libvirt_private.syms | 4 +
src/qemu/qemu_capabilities.c | 5 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 104 +++++++
src/qemu/qemu_command.h | 4 +
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain_address.c | 183 ++++++++++-
src/qemu/qemu_hotplug.c | 175 ++++++++++-
src/util/virpci.h | 13 +
tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 +
tests/qemuxml2argvdata/disk-virtio-s390-zpci.args | 27 ++
tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml | 17 +
.../hostdev-vfio-zpci-autogenerate.args | 24 ++
.../hostdev-vfio-zpci-autogenerate.xml | 18 ++
.../hostdev-vfio-zpci-boundaries.args | 27 ++
.../hostdev-vfio-zpci-boundaries.xml | 26 ++
.../hostdev-vfio-zpci-multidomain-many.args | 38 +++
.../hostdev-vfio-zpci-multidomain-many.xml | 67 ++++
tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 24 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 19 ++
tests/qemuxml2argvtest.c | 21 ++
tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml | 29 ++
tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 30 ++
tests/qemuxml2xmltest.c | 3 +
38 files changed, 1347 insertions(+), 22 deletions(-)
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
--
2.16.3
6 years, 6 months
[libvirt] [ v3 0/4] Introduce network-backed loader & NVRAM.
by Prerna Saxena
Libvirt domain XML allows only local filepaths to specify a loader element
or its matching NVRAM. Given that VMs may themselves move across hypervisor
hosts, it should be possible to allocate loaders/NVRAM disks on network storage
for uninterrupted access.
This series extends the loader & NVRAM disk elements to be described as
virStorageSource* elements, as discussed in :
https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html
Sample XML with new annotation:
<loader readonly='yes' type='pflash' backing='file'>
<source file='/usr/share/OVMF/OVMF_CODE.fd'/>
</loader>
<nvram backing='network'>
<source protocol='iscsi' name='iqn.2013-07.com.example:iscsi-nopool/0'>
<host name='example.com' port='6000'/>
</source>
</nvram>
References:
----------
v0/ Proposal: https://www.redhat.com/archives/libvir-list/2018-March/msg01721.html.v1
v1: https://www.redhat.com/archives/libvir-list/2018-April/msg02024.html
v2: https://www.redhat.com/archives/libvir-list/2018-May/msg00948.html
Changelog:
---------
Changes since v2:
- Consolidated patches with related data structures to avoid build breakage.
- Passes make check & make syntax-check.
Prerna Saxena (4):
Schema: Introduce XML schema for network-backed loader and nvram
elements.
Loader: Add a more elaborate definition.
Test: Add a test snippet to evaluate command line generation for
loader/nvram specified via virStorageSource
Documentation: Add a blurb for the newly added XML snippets for loader
and nvram.
docs/formatdomain.html.in | 36 +++-
docs/schemas/domaincommon.rng | 108 +++++++++--
src/bhyve/bhyve_command.c | 6 +-
src/conf/domain_conf.c | 250 +++++++++++++++++++++++--
src/conf/domain_conf.h | 11 +-
src/qemu/qemu_cgroup.c | 13 +-
src/qemu/qemu_command.c | 21 ++-
src/qemu/qemu_domain.c | 31 ++-
src/qemu/qemu_driver.c | 7 +-
src/qemu/qemu_parse_command.c | 30 ++-
src/qemu/qemu_process.c | 54 ++++--
src/security/security_dac.c | 6 +-
src/security/security_selinux.c | 6 +-
src/security/virt-aa-helper.c | 14 +-
src/vbox/vbox_common.c | 11 +-
src/xenapi/xenapi_driver.c | 4 +-
src/xenconfig/xen_sxpr.c | 19 +-
src/xenconfig/xen_xm.c | 9 +-
tests/qemuxml2argvdata/bios-nvram-network.args | 31 +++
tests/qemuxml2argvdata/bios-nvram-network.xml | 42 +++++
tests/qemuxml2argvtest.c | 1 +
21 files changed, 606 insertions(+), 104 deletions(-)
create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.args
create mode 100644 tests/qemuxml2argvdata/bios-nvram-network.xml
--
1.8.1.2
6 years, 6 months
[libvirt] [PATCH] qemu: Honour <on_reboot/>
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1476866
For some reason, we completely ignore <on_reboot/> setting for
domains. The implementation is simply not there. It never was.
However, things are slightly more complicated. QEMU sends us two
RESET events on domain reboot. Fortunately, the event contains
this 'guest' field telling us who initiated the reboot. And since
we don't want to destroy the domain if the reset is initiated by
a user, we have to ignore those events. Whatever, just look at
the code.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_monitor.c | 4 ++--
src/qemu/qemu_monitor.h | 3 ++-
src/qemu/qemu_monitor_json.c | 8 +++++++-
src/qemu/qemu_process.c | 34 ++++++++++++++++++++++++++++++----
5 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h
index 4c9050aff..d865e67c7 100644
--- a/src/qemu/qemu_domain.h
+++ b/src/qemu/qemu_domain.h
@@ -233,6 +233,7 @@ struct _qemuDomainObjPrivate {
bool agentError;
bool gotShutdown;
+ bool gotReset;
bool beingDestroyed;
char *pidfile;
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index 19082d8bf..8f81a2b28 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -1344,12 +1344,12 @@ qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest)
int
-qemuMonitorEmitReset(qemuMonitorPtr mon)
+qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest)
{
int ret = -1;
VIR_DEBUG("mon=%p", mon);
- QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm);
+ QEMU_MONITOR_CALLBACK(mon, ret, domainReset, mon->vm, guest);
return ret;
}
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 31f7e97ba..8c33f6783 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -134,6 +134,7 @@ typedef int (*qemuMonitorDomainShutdownCallback)(qemuMonitorPtr mon,
void *opaque);
typedef int (*qemuMonitorDomainResetCallback)(qemuMonitorPtr mon,
virDomainObjPtr vm,
+ virTristateBool guest,
void *opaque);
typedef int (*qemuMonitorDomainPowerdownCallback)(qemuMonitorPtr mon,
virDomainObjPtr vm,
@@ -346,7 +347,7 @@ int qemuMonitorEmitEvent(qemuMonitorPtr mon, const char *event,
long long seconds, unsigned int micros,
const char *details);
int qemuMonitorEmitShutdown(qemuMonitorPtr mon, virTristateBool guest);
-int qemuMonitorEmitReset(qemuMonitorPtr mon);
+int qemuMonitorEmitReset(qemuMonitorPtr mon, virTristateBool guest);
int qemuMonitorEmitPowerdown(qemuMonitorPtr mon);
int qemuMonitorEmitStop(qemuMonitorPtr mon);
int qemuMonitorEmitResume(qemuMonitorPtr mon);
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index b8a68154a..8a1501ced 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -536,7 +536,13 @@ static void qemuMonitorJSONHandleShutdown(qemuMonitorPtr mon, virJSONValuePtr da
static void qemuMonitorJSONHandleReset(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED)
{
- qemuMonitorEmitReset(mon);
+ bool guest = false;
+ virTristateBool guest_initiated = VIR_TRISTATE_BOOL_ABSENT;
+
+ if (data && virJSONValueObjectGetBoolean(data, "guest", &guest) == 0)
+ guest_initiated = guest ? VIR_TRISTATE_BOOL_YES : VIR_TRISTATE_BOOL_NO;
+
+ qemuMonitorEmitReset(mon, guest_initiated);
}
static void qemuMonitorJSONHandlePowerdown(qemuMonitorPtr mon, virJSONValuePtr data ATTRIBUTE_UNUSED)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 0aecce3b1..889efc7f0 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -478,27 +478,51 @@ qemuProcessFindVolumeQcowPassphrase(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
static int
qemuProcessHandleReset(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
virDomainObjPtr vm,
+ virTristateBool guest_initiated,
void *opaque)
{
virQEMUDriverPtr driver = opaque;
- virObjectEventPtr event;
+ virObjectEventPtr event = NULL;
qemuDomainObjPrivatePtr priv;
virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+ bool callOnReboot = false;
virObjectLock(vm);
+ priv = vm->privateData;
+
+ /* This is a bit tricky. When a guest does 'reboot' we receive RESET event
+ * twice, both times it's guest initiated. However, if users call 'virsh
+ * reset' we still receive two events but the first one is guest_initiated
+ * = no, the second one is guest_initiated = yes. Therefore, to avoid
+ * executing onReboot action in the latter case we need this complicated
+ * construction. */
+ if (guest_initiated == VIR_TRISTATE_BOOL_NO) {
+ VIR_DEBUG("Ignoring not guest initiated RESET event from domain %s",
+ vm->def->name);
+ priv->gotReset = true;
+ } else if (priv->gotReset && guest_initiated == VIR_TRISTATE_BOOL_YES) {
+ VIR_DEBUG("Ignoring second RESET event from domain %s",
+ vm->def->name);
+ priv->gotReset = false;
+ } else {
+ callOnReboot = true;
+ }
+
event = virDomainEventRebootNewFromObj(vm);
- priv = vm->privateData;
if (priv->agent)
qemuAgentNotifyEvent(priv->agent, QEMU_AGENT_EVENT_RESET);
if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, vm, driver->caps) < 0)
VIR_WARN("Failed to save status on vm %s", vm->def->name);
+ if (callOnReboot &&
+ guest_initiated == VIR_TRISTATE_BOOL_YES &&
+ vm->def->onReboot == VIR_DOMAIN_LIFECYCLE_DESTROY)
+ qemuProcessShutdownOrReboot(driver, vm);
+
virObjectUnlock(vm);
-
qemuDomainEventQueue(driver, event);
-
virObjectUnref(cfg);
return 0;
}
@@ -555,6 +579,7 @@ qemuProcessFakeReboot(void *opaque)
goto endjob;
}
priv->gotShutdown = false;
+ priv->gotReset = false;
event = virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_RESUMED,
VIR_DOMAIN_EVENT_RESUMED_UNPAUSED);
@@ -5320,6 +5345,7 @@ qemuProcessPrepareDomain(virConnectPtr conn,
priv->monError = false;
priv->monStart = 0;
priv->gotShutdown = false;
+ priv->gotReset = false;
VIR_DEBUG("Updating guest CPU definition");
if (qemuProcessUpdateGuestCPU(vm->def, priv->qemuCaps, caps, flags) < 0)
--
2.13.0
6 years, 6 months
[libvirt] [RFC PATCH 0/6] qemu: Support pagesize tuning for pSeries guests
by Andrea Bolognani
The QEMU part, which is RFC as well, can be found at
http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg02818.html
Applies cleanly on top of c49013f26c6b40b741f4d5fc61269898f7fd25b8.
Andrea Bolognani (6):
conf: Reintroduce virDomainDef::hpt_resizing
conf: Tweak HPT parsing and formatting
qemu: Introduce QEMU_CAPS_MACHINE_PSERIES_CAP_HPT_MPS
tests: Pretend we have pseries.cap-hpt-mps in 2.12
conf: Parse and format HPT maxpagesize
qemu: Format pseries.cap-hpt-mps on the command line
docs/schemas/domaincommon.rng | 21 +-
src/conf/domain_conf.c | 72 ++++++-
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 8 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 57 ++++--
src/qemu/qemu_domain.c | 2 +-
.../caps_2.12.0.aarch64.replies | 24 ++-
.../caps_2.12.0.aarch64.xml | 2 +-
.../caps_2.12.0.ppc64.replies | 180 +++++++++++++++++-
.../caps_2.12.0.ppc64.xml | 3 +-
.../caps_2.12.0.s390x.replies | 26 ++-
.../caps_2.12.0.s390x.xml | 2 +-
.../caps_2.12.0.x86_64.replies | 30 +--
.../caps_2.12.0.x86_64.xml | 2 +-
tests/qemuxml2argvdata/pseries-features.args | 3 +-
tests/qemuxml2argvdata/pseries-features.xml | 18 +-
tests/qemuxml2argvtest.c | 1 +
tests/qemuxml2xmloutdata/pseries-features.xml | 31 ++-
tests/qemuxml2xmltest.c | 1 +
20 files changed, 401 insertions(+), 85 deletions(-)
mode change 120000 => 100644 tests/qemuxml2xmloutdata/pseries-features.xml
--
2.17.0
6 years, 6 months
