[libvirt] [PATCH] qemu: Restore lost shutdown reason
by John Ferlan
When qemuProcessReconnectHelper was introduced (commit d38897a5d)
reconnection failure used VIR_DOMAIN_SHUTOFF_FAILED; however, that
was changed in commit bda2f17d to either VIR_DOMAIN_SHUTOFF_CRASHED
or VIR_DOMAIN_SHUTOFF_UNKNOWN.
When QEMU_CAPS_NO_SHUTDOWN checking was removed in commit fe35b1ad6
the conditional state was just left at VIR_DOMAIN_SHUTOFF_CRASHED.
Restore the logic adjustment using the same conditions as command
line building and alter the comment to describe the reasoning.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
This was "discovered" while reviewing Nikolay's patch related
to adding "DAEMON" as the shutdown reason:
https://www.redhat.com/archives/libvir-list/2018-October/msg00493.html
While working through the iterations of that - figured I'd at
least post this.
src/qemu/qemu_process.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 3955eda17c..4a39111d51 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -7985,11 +7985,16 @@ qemuProcessReconnect(void *opaque)
if (virDomainObjIsActive(obj)) {
/* We can't get the monitor back, so must kill the VM
* to remove danger of it ending up running twice if
- * user tries to start it again later
- * If we couldn't get the monitor since QEMU supports
- * no-shutdown, we can safely say that the domain
- * crashed ... */
- state = VIR_DOMAIN_SHUTOFF_CRASHED;
+ * user tries to start it again later.
+ *
+ * If we cannot get to the monitor when the QEMU command
+ * line used -no-shutdown, then we can safely say that the
+ * domain crashed; otherwise we don't really know. */
+ if (priv->monJSON && priv->allowReboot == VIR_TRISTATE_BOOL_YES)
+ state = VIR_DOMAIN_SHUTOFF_CRASHED;
+ else
+ state = VIR_DOMAIN_SHUTOFF_UNKNOWN;
+
/* If BeginJob failed, we jumped here without a job, let's hope another
* thread didn't have a chance to start playing with the domain yet
* (it's all we can do anyway).
--
2.17.2
6 years
[libvirt] [PATCH] nodedev: Document the udevEventHandleThread
by John Ferlan
Add details of the algorithm and why it was used to help future
readers understand the issues encountered. Based largely off a
description provided by Erik Skultety <eskultet(a)redhat.com>.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
see: https://www.redhat.com/archives/libvir-list/2018-October/msg00915.html
src/node_device/node_device_udev.c | 49 ++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index 22897591de..8ca81e65ad 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -1591,6 +1591,53 @@ udevEventMonitorSanityCheck(udevEventDataPtr priv,
}
+/**
+ * udevEventHandleThread
+ * @opaque: unused
+ *
+ * Thread to handle the udevEventHandleCallback processing when udev
+ * tells us there's a device change for us (add, modify, delete, etc).
+ *
+ * Management of the processing udev device notification is a delicate
+ * balance between the udev process, the scheduler, and when exactly the
+ * data from/for the socket is received. The udev processing code notifies
+ * the udevEventHandleCallback that it has data; however, the actual recv()
+ * done in the udev code to fill in the @device structure can be delayed
+ * due to how threads are scheduled.
+ *
+ * As it turns out, the event loop could be scheduled (and it in fact
+ * was) earlier than the handler thread. What that essentially means is
+ * that by the time the thread actually handled the event and read the
+ * data from the monitor, the event loop fired the very same event, simply
+ * because the data hadn't been retrieved from the socket at that point yet.
+ *
+ * Thus this algorithm is that once udevEventHandleCallback is notified
+ * there is data, this loop will process as much data as possible until
+ * udev_monitor_receive_device fails to get the @device. This may be
+ * because we've processed everything or because the scheduling thread
+ * hasn't been able to populate data in the socket. Once we're done
+ * processing everything we can, wait on the next event/notification.
+ * Although this may incur a slight delay if the socket data wasn't
+ * populated, the event/notifications are fairly consistent so there's
+ * no need to use virCondWaitUntil.
+ *
+ * NB: Usage of event based socket algorithm causes some issues with
+ * older platforms such as CentOS 6 in which the data socket is opened
+ * without the NONBLOCK bit set. Still even if the reset of priv->dataReady
+ * were moved to just after the udev_monitor_receive_device in order to
+ * avoid the NONBLOCK issue, the scheduler would still come into play
+ * especially for environments when multiple devices are added into the
+ * system. Even those environments would still be blocked on the udev
+ * socket recv() call. The algorithm for handling that scenario would
+ * be more complex and involve pulling the monitor object out of the
+ * private data lockable object and would need to be guarded by a
+ * separate lock. Devising algorithms to work around issues with older
+ * OS's at the expense of more modern OS algorithms in newer event
+ * processing code may result in unexpected issues, so the choice is
+ * to encourage use of newer OS's with newer udev event processing code.
+ * Newer devices, such as mdevs make heavy usage of event processing
+ * and it's expected future devices would follow that model.
+ */
static void
udevEventHandleThread(void *opaque ATTRIBUTE_UNUSED)
{
@@ -1637,6 +1684,8 @@ udevEventHandleThread(void *opaque ATTRIBUTE_UNUSED)
return;
}
+ /* See the above description why this needs to be here
+ * and not after the udev_monitor_receive_device. */
virObjectLock(priv);
priv->dataReady = false;
virObjectUnlock(priv);
--
2.17.2
6 years
[libvirt] [PATCH] qemu: Report warning if QoS is set for vhostuser interface
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1524230
Because of historical reasons, we are not denying starting a
domain which has QoS set for unsupported type of device. We do
report just a warning instead. And even though we perhaps used to
do so for vhostuser it got lost somewhere. Bring it back.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_command.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 6e3ff67660..489e8bc689 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -8246,6 +8246,12 @@ qemuBuildVhostuserCommandLine(virQEMUDriverPtr driver,
goto cleanup;
}
+ if (virDomainNetGetActualBandwidth(net)) {
+ VIR_WARN("setting bandwidth on interfaces of "
+ "type '%s' is not implemented yet",
+ virDomainNetTypeToString(VIR_DOMAIN_NET_TYPE_VHOSTUSER));
+ }
+
switch ((virDomainChrType)net->data.vhostuser->type) {
case VIR_DOMAIN_CHR_TYPE_UNIX:
if (!(chardev = qemuBuildChrChardevStr(logManager, secManager,
--
2.18.1
6 years
[libvirt] [PATCH v2] vhost-user: define conventions for vhost-user backends
by Marc-André Lureau
As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
review, let's define a common set of backend conventions to help with
management layer implementation, and interoperability.
v2:
- drop --pidfile
- add some notes about daemonizing & stdin/out/err
Cc: libvir-list(a)redhat.com
Cc: Gerd Hoffmann <kraxel(a)redhat.com>
Cc: Daniel P. Berrangé <berrange(a)redhat.com>
Cc: Changpeng Liu <changpeng.liu(a)intel.com>
Cc: Dr. David Alan Gilbert <dgilbert(a)redhat.com>
Cc: Felipe Franciosi <felipe(a)nutanix.com>
Cc: Gonglei <arei.gonglei(a)huawei.com>
Cc: Maxime Coquelin <maxime.coquelin(a)redhat.com>
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: Victor Kaplansky <victork(a)redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com>
---
docs/interop/vhost-user.txt | 109 +++++++++++++++++++++++++++++++++++-
1 file changed, 107 insertions(+), 2 deletions(-)
diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index ba5e37d714..339b335e9c 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -17,8 +17,13 @@ The protocol defines 2 sides of the communication, master and slave. Master is
the application that shares its virtqueues, in our case QEMU. Slave is the
consumer of the virtqueues.
-In the current implementation QEMU is the Master, and the Slave is intended to
-be a software Ethernet switch running in user space, such as Snabbswitch.
+In the current implementation QEMU is the Master, and the Slave is the
+external process consuming the virtio queues, for example a software
+Ethernet switch running in user space, such as Snabbswitch, or a block
+device backend processing read & write to a virtual disk. In order to
+facilitate interoperability between various backend implementations,
+it is recommended to follow the "Backend program conventions"
+described in this document.
Master and slave can be either a client (i.e. connecting) or server (listening)
in the socket communication.
@@ -859,3 +864,103 @@ resilient for selective requests.
For the message types that already solicit a reply from the client, the
presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or need_reply bit being set brings
no behavioural change. (See the 'Communication' section for details.)
+
+Backend program conventions
+---------------------------
+
+vhost-user backends provide various services and they may need to be
+configured manually depending on the use case. However, it is a good
+idea to follow the conventions listed here when possible. Users, QEMU
+or libvirt, can then rely on some common behaviour to avoid
+heterogenous configuration and management of the backend program and
+facilitate interoperability.
+
+In order to be discoverable, default vhost-user backends should be
+located under "/usr/libexec", and be named "vhost-user-$device" where
+"$device" is the device name in lower-case following the name listed
+in the Linux virtio_ids.h header (ex: the VIRTIO_ID_RPROC_SERIAL
+backend would be named "vhost-user-rproc-serial").
+
+Mechanisms to list, and to select among alternatives implementations
+or modify the default backend are not described at this point (a
+distribution may use update-alternatives, for example, to list and to
+pick a different default backend).
+
+The backend program must not daemonize itself, but it may be
+daemonized by the management layer. It may also have a restricted
+access to the system.
+
+File descriptors 0, 1 and 2 will exist, and have regular
+stdin/stdout/stderr usage (they may be redirected to /dev/null by the
+management layer, or to a log handler).
+
+The backend program must end (as quickly and cleanly as possible) when
+the SIGTERM signal is received. Eventually, it may be SIGKILL by the
+management layer after a few seconds.
+
+The following command line options have an expected behaviour. They
+are mandatory, unless explicitly said differently:
+
+* --socket-path=PATH
+
+This option specify the location of the vhost-user Unix domain socket.
+It is incompatible with --fd.
+
+* --fd=FDNUM
+
+When this argument is given, the backend program is started with the
+vhost-user socket as file descriptor FDNUM. It is incompatible with
+--socket-path.
+
+* --print-capabilities
+
+Output to stdout a line-seperated list of backend capabilities, and
+then exit successfully. Other options and arguments should be ignored,
+and the backend program should not perform its normal function.
+
+At the time of writing, there are no common capabilities. Some
+device-specific capabilities are listed in the respective sections. By
+convention, device-specific capabilities are prefixed by their device
+name.
+
+vhost-user-input program conventions
+------------------------------------
+
+Capabilities:
+
+input-evdev-path
+
+ The --evdev-path command line option is supported.
+
+input-no-grab
+
+ The --no-grab command line option is supported.
+
+* --evdev-path=PATH (optional)
+
+Specify the linux input device.
+
+* --no-grab (optional)
+
+Do no request exclusive access to the input device.
+
+vhost-user-gpu program conventions
+----------------------------------
+
+Capabilities:
+
+gpu-render-node
+
+ The --render-node command line option is supported.
+
+gpu-virgl
+
+ The --virgl command line option is supported.
+
+* --render-node=PATH (optional)
+
+Specify the GPU DRM render node.
+
+* --virgl (optional)
+
+Enable virgl rendering support.
--
2.19.0
6 years
[libvirt] [PATCH] libxl: add support for soft reset
by Jim Fehlig
The pvops Linux kernel implements machine_ops.crash_shutdown as
static void xen_hvm_crash_shutdown(struct pt_regs *regs)
{
native_machine_crash_shutdown(regs);
xen_reboot(SHUTDOWN_soft_reset);
}
but currently the libxl driver does not handle the soft reset
shutdown event. As a result, the guest domain never proceeds
past xen_reboot(), making it impossible for HVM domains to save
a crash dump using kexec.
This patch adds support for handling the soft reset event by
calling libxl_domain_soft_reset() and re-enabling domain death
events, which is similar to the xl tool handling of soft reset
shutdown event.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 0032b9dd11..295ec04a85 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -447,8 +447,10 @@ libxlDomainShutdownThread(void *opaque)
virObjectEventPtr dom_event = NULL;
libxl_shutdown_reason xl_reason = ev->u.domain_shutdown.shutdown_reason;
libxlDriverConfigPtr cfg;
+ libxl_domain_config d_config;
cfg = libxlDriverConfigGet(driver);
+ libxl_domain_config_init(&d_config);
vm = virDomainObjListFindByID(driver->domains, ev->domid);
if (!vm) {
@@ -532,6 +534,33 @@ libxlDomainShutdownThread(void *opaque)
* after calling libxl_domain_suspend() are handled by it's callers.
*/
goto endjob;
+ } else if (xl_reason == LIBXL_SHUTDOWN_REASON_SOFT_RESET) {
+ libxlDomainObjPrivatePtr priv = vm->privateData;
+ int res;
+
+ if (libxl_retrieve_domain_configuration(cfg->ctx, vm->def->id,
+ &d_config) != 0) {
+ VIR_ERROR(_("Failed to retrieve config for VM '%s'. "
+ "Unable to perform soft reset. Destroying VM"),
+ vm->def->name);
+ goto destroy;
+ }
+
+ if (priv->deathW) {
+ libxl_evdisable_domain_death(cfg->ctx, priv->deathW);
+ priv->deathW = NULL;
+ }
+
+ res = libxl_domain_soft_reset(cfg->ctx, &d_config, vm->def->id,
+ NULL, NULL);
+ if (res != 0) {
+ VIR_ERROR(_("Failed to soft reset VM '%s'. Destroying VM"),
+ vm->def->name);
+ goto destroy;
+ }
+ libxl_evenable_domain_death(cfg->ctx, vm->def->id, 0, &priv->deathW);
+ libxl_domain_unpause(cfg->ctx, vm->def->id);
+ goto endjob;
} else {
VIR_INFO("Unhandled shutdown_reason %d", xl_reason);
goto endjob;
@@ -565,6 +594,7 @@ libxlDomainShutdownThread(void *opaque)
virObjectEventStateQueue(driver->domainEventState, dom_event);
libxl_event_free(cfg->ctx, ev);
VIR_FREE(shutdown_info);
+ libxl_domain_config_dispose(&d_config);
virObjectUnref(cfg);
}
--
2.18.0
6 years
[libvirt] [PATCH v2 0/3] qemu: guest dedicated crypto adapters
by Boris Fiuczynski
v2:
+ added singleton check for vfio-ap mediated device
This patch series introduces initial libvirt support for guest
dedicated crypto adapters on S390.
It allows to specify a vfio-ap mediated device in a domain.
Extensive documentation about AP is available in patch 6 of
the QEMU patch series.
KVM/kernel: guest dedicated crypto adapters
https://lkml.org/lkml/2018/9/26/25
QEMU: s390x: vfio-ap: guest dedicated crypto adapters
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg01993.html
The qemu patch series has been included into master.
https://git.qemu.org/?p=qemu.git;a=commit;h=69ac8c4cb93f2685839ff7b857cef...
Boris Fiuczynski (3):
qemu: add vfio-ap capability
qemu: vfio-ap device support
news: Update news for vfio-ap support
docs/formatdomain.html.in | 3 ++-
docs/news.xml | 9 +++++++++
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 28 ++++++++++++++++++++++++++++
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 8 ++++++++
src/qemu/qemu_domain_address.c | 4 ++++
src/util/virmdev.c | 3 ++-
src/util/virmdev.h | 1 +
10 files changed, 58 insertions(+), 2 deletions(-)
--
2.17.0
6 years
[libvirt] [PATCH 0/3] RfC: add support for deprecated devices.
by Gerd Hoffmann
Works simliar to machine types, by adding a deprecation_reason field
(using the same name for easy grepping). Also deprecate two devices:
adlib and cirrus.
This is tagged as RfC because the deprecation notice is not added to
introspecction yet.
Gerd Hoffmann (3):
qdev: add deprecation_reason to DeviceClass
adlib: mark as insecure and deprecated.
cirrus: mark as deprecated
hw/audio/adlib.c | 1 +
hw/core/qdev.c | 9 ++++++++-
hw/display/cirrus_vga.c | 2 ++
hw/display/cirrus_vga_isa.c | 2 ++
include/hw/qdev-core.h | 1 +
qdev-monitor.c | 7 +++++++
qemu-deprecated.texi | 8 ++++++++
7 files changed, 29 insertions(+), 1 deletion(-)
--
2.9.3
6 years
[libvirt] RFC: "Determine if the domain has been updated."?
by Philipp Hahn
Hello,
<https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainIsUpdated> states:
> int virDomainIsUpdated (virDomainPtr dom)
>
> Determine if the domain has been updated.
>
> dom: pointer to the domain object
> Returns: 1 if updated, 0 if not, -1 on error
Not very enlightening :-(
So what's the meaning of "updated" here: "inactive XML got changed but
the currently running VM was started from a different XML"?
Only very few drivers seem to mention it at all and they seem to mean
different things. Any nobody seems to update the variable, only 4 readers:
> $ git grep -ne '->updated'
> libxl/libxl_driver.c:4844: ret = vm->updated;
> lxc/lxc_driver.c:343: ret = obj->updated;
> qemu/qemu_driver.c:1628: ret = obj->updated;
> uml/uml_driver.c:1456: ret = obj->updated;
Thank you for the clarification.
Philipp
--
Philipp Hahn
Open Source Software Engineer
Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
hahn(a)univention.de
http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876
6 years
Re: [libvirt] [PATCH v3 0/3] Deprecate QMP & HMP `cpu-add`; document vCPU hotplug
by Kashyap Chamarthy
[Cc: libvir-list]
On Tue, Oct 30, 2018 at 01:35:23PM +0100, Kashyap Chamarthy wrote:
> The first patch deprecates the QMP `cpu-add`, the second its HMP
> equivalent, and the third documents vCPU hotplug procedure using QMP
> `device_add` et al.
>
> v2: https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg03191.html
>
> Kashyap Chamarthy (3):
> Deprecate QMP `cpu-add`
> Deprecate HMP `cpu-add`
> docs: Document vCPU hotplug procedure
>
> docs/cpu-hotplug.rst | 142 +++++++++++++++++++++++++++++++++++++++++++
> hmp-commands.hx | 6 +-
> hmp.c | 2 +
> qapi/misc.json | 8 ++-
> qemu-deprecated.texi | 5 ++
> 5 files changed, 160 insertions(+), 3 deletions(-)
> create mode 100644 docs/cpu-hotplug.rst
>
> --
> 2.17.1
>
--
/kashyap
6 years
