[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang
Seems a backport miss. An extra member is passed to struct
virLXCBasicMountInfo.
Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn>
---
src/lxc/lxc_container.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 28dabec..1c65fa9 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -760,7 +760,7 @@ typedef struct {
static const virLXCBasicMountInfo lxcBasicMounts[] = {
{ "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false },
- { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false },
+ { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true },
#if WITH_SELINUX
--
1.7.1
11 months, 2 weeks
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
11 months, 2 weeks
[libvirt] [PATCH v4 0/8] Virtio-crypto device support
by Longpeng(Mike)
As virtio-crypto has been supported in QEMU 2.8 and the frontend
driver has been merged in linux 4.10, so it's necessary to support
virtio-crypto in libvirt.
---
Changes since v3:
- spilt the capabilities part into a separate patch. [Boris]
- include Boris's virtio-crypto ccw support(PATCH 6 & 8). [Boris]
- add the missing capabilities in caps_2.9.0.x86_64.xml. [Boris]
- fix Indentation and missing virDomainCryptoDefFree. [Marc]
Changes since v2:
- PATCH 1: modify docs as Martin & Boris's suggestion. [Martin & Boris]
- PATCH 2: add the missing 'ToString'. [Martin]
- PATCH 3: use virAsprintf instead of virBufferAsprintf. [Martin]
remove pointless virBufferCheckError. [Martin]
- rebase on master. [Longpeng]
Changes since v1:
- split patch [Martin]
- rebase on master [Martin]
- add docs/tests/schema [Martin]
- fix typos [Gonglei]
---
Boris Fiuczynski (2):
qemu: virtio-crypto: add ccw support
qemu: virtio-crypto: add test for ccw support
Longpeng(Mike) (6):
docs: schema: Add basic documentation for the virtual
docs: news: Add virtio-crypto devices
conf: Parse virtio-crypto in the domain XML
caps: Add qemu capabilities about virtio-crypto
qemu: Implement support for 'builtin' backend for virtio-crypto
tests: Add testcase for virtio-crypto parsing
docs/formatdomain.html.in | 61 ++++++
docs/news.xml | 10 +
docs/schemas/domaincommon.rng | 30 +++
src/conf/domain_conf.c | 213 ++++++++++++++++++++-
src/conf/domain_conf.h | 32 ++++
src/libvirt_private.syms | 5 +
src/qemu/qemu_alias.c | 20 ++
src/qemu/qemu_alias.h | 3 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 130 +++++++++++++
src/qemu/qemu_command.h | 3 +
src/qemu/qemu_domain_address.c | 25 +++
src/qemu/qemu_driver.c | 6 +
src/qemu/qemu_hotplug.c | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +
.../qemuxml2argv-virtio-crypto-builtin.xml | 26 +++
.../qemuxml2argv-virtio-crypto-ccw.args | 22 +++
.../qemuxml2argv-virtio-crypto-ccw.xml | 16 ++
.../qemuxml2argv-virtio-crypto.args | 22 +++
tests/qemuxml2argvtest.c | 6 +
.../qemuxml2xmlout-virtio-crypto-builtin.xml | 31 +++
tests/qemuxml2xmltest.c | 2 +
25 files changed, 679 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-builtin.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto.args
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-crypto-builtin.xml
--
1.8.3.1
5 years, 10 months
[libvirt] [RFC] cgroup settings and systemd daemon-reload conflict
by Nikolay Shirokovskiy
Hi, all.
It turns out that systemd daemon-reload reset settings that are managable
thru 'systemctl set-property' interface.
> virsh schedinfo tst3 | grep global_quota
global_quota : -1
> virsh schedinfo tst3 --set global_quota=50000 | grep global_quota
global_quota : 50000
> systemctl daemon-reload
> virsh schedinfo tst3 | grep global_quota
global_quota : -1
This behaviour does not limited to cpu controller, same for blkio for example.
I checked different versions of systemd (219 - Feb 15, and quite recent 236 - Dec 17)
to make sure it is not kind of bug of old version. So systemd does not play well
with direct writes to cgroup parameters that managable thru systemd. Looks like
libvirtd needs to use systemd's dbus interface to change all such parameters.
I only wonder how this can be unnoticed for such long time (creating cgroup for domain
thru systemd - Jul 2013) as daemon-reload is called upon libvirtd package update. May
be I miss something?
Nikolay
6 years
[libvirt] [PATCH 0/9] Resolve libvirtd hang on termination with connected long running client
by John Ferlan
RFC:
https://www.redhat.com/archives/libvir-list/2018-January/msg00318.html
Adjustments since RFC...
Patches 1&2: No change, were already R-B'd
Patch 3: Removed code as noted in code review, update commit message
Patch 4: From old series removed, see below for more details
Patch 9: no change
NB: Patches 5-8 and 10 from Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com>
are removed as they seemed to not be necessary
Replaced the former patch 4 with series of patches to (slowly) provide
support to disable new connections, handle removing waiting jobs, causing
the waiting workers to quit, and allow any running jobs to complete.
As it turns out, waiting for running jobs to complete cannot be done
from the virNetServerClose callbacks because that means the event loop
processing done during virNetServerRun will not allow any currently
long running worker job thread a means to complete.
So when virNetDaemonQuit is called as a result of the libvirtd signal
handlers for SIG{QUIT|INT|TERM}, instead of just causing virNetServerRun
to quit immediately, alter to using a quitRequested flag and then use
that quitRequested flag to check for long running worker threads before
causing the event loop to quit resulting in libvirtd being able to run
through the virNetDaemonClose processing.
John Ferlan (9):
libvirtd: Alter refcnt processing for domain server objects
libvirtd: Alter refcnt processing for server program objects
netserver: Remove ServiceToggle during ServerDispose
util: Introduce virThreadPoolDrain
rpc: Introduce virNetServerQuitRequested
rpc: Introduce virNetServerWorkerCount
rpc: Alter virNetDaemonQuit processing
docs: Add news article for libvirtd issue
APPLY ONLY FOR TESTING PURPOSES
daemon/libvirtd.c | 43 +++++++++++++++++++++++---------
docs/news.xml | 12 +++++++++
src/libvirt_private.syms | 1 +
src/libvirt_remote.syms | 2 ++
src/qemu/qemu_driver.c | 5 ++++
src/rpc/virnetdaemon.c | 45 +++++++++++++++++++++++++++++++++-
src/rpc/virnetserver.c | 52 ++++++++++++++++++++++++++++++++++++---
src/rpc/virnetserver.h | 4 +++
src/util/virthreadpool.c | 64 ++++++++++++++++++++++++++++++++++++++++--------
src/util/virthreadpool.h | 2 ++
10 files changed, 204 insertions(+), 26 deletions(-)
--
2.13.6
6 years, 3 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, 3 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, 4 months
[libvirt] [PATCH] qemu: cpu: fix fullCPU to include all emulatable qemu features
by Nikolay Shirokovskiy
On Core i5 650 guest fail to start with error [1] if guest cpu config is taken
from domcapabilities and check is set to partial.
The problem is in qemu caps fullCPU calculation in virQEMUCapsInitHostCPUModel.
It is supposed to include features emulated by qemu and missed on host. Some of
such features may be not included however.
For mentioned cpu host cpu is detected as Westmere and guest cpu as
SandyBridge. x2apic is missed on host and provided by installed qemu. The
feature is not mentioned in guest cpu features explicitly because SandyBridge
model include it. As a result fullCPU does not include x2apic too.
Solution is to expand guest cpu features before updating fullCPU features.
[1] error: the CPU is incompatible with host CPU: Host CPU does not
provide required features: x2apic, tsc-deadline
---
src/qemu/qemu_capabilities.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9c1eeac..edba716 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3475,6 +3475,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virDomainVirtType type)
{
virCPUDefPtr cpu = NULL;
+ virCPUDefPtr cpuExpanded = NULL;
virCPUDefPtr migCPU = NULL;
virCPUDefPtr hostCPU = NULL;
virCPUDefPtr fullCPU = NULL;
@@ -3504,9 +3505,13 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
NULL, NULL)))
goto error;
- for (i = 0; i < cpu->nfeatures; i++) {
- if (cpu->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
- virCPUDefUpdateFeature(fullCPU, cpu->features[i].name,
+ if (!(cpuExpanded = virCPUDefCopy(cpu)) ||
+ virCPUExpandFeatures(qemuCaps->arch, cpuExpanded) < 0)
+ goto error;
+
+ for (i = 0; i < cpuExpanded->nfeatures; i++) {
+ if (cpuExpanded->features[i].policy == VIR_CPU_FEATURE_REQUIRE &&
+ virCPUDefUpdateFeature(fullCPU, cpuExpanded->features[i].name,
VIR_CPU_FEATURE_REQUIRE) < 0)
goto error;
}
@@ -3528,6 +3533,7 @@ virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps,
virQEMUCapsSetHostModel(qemuCaps, type, cpu, migCPU, fullCPU);
cleanup:
+ virCPUDefFree(cpuExpanded);
virCPUDefFree(hostCPU);
return;
--
1.8.3.1
6 years, 6 months
[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
6 years, 6 months