[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..



Hi Rahul,

On 13/04/2022 09:25, Rahul Singh wrote:
On 11 Apr 2022, at 7:01 pm, Julien Grall <julien@xxxxxxx> wrote:
Signed-off-by: Rahul Singh <rahul.singh@xxxxxxx>
---
docs/designs/dom0less-evtchn.md | 96 +++++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 docs/designs/dom0less-evtchn.md
diff --git a/docs/designs/dom0less-evtchn.md b/docs/designs/dom0less-evtchn.md
new file mode 100644
index 0000000000..6a1b7e8c22
--- /dev/null
+++ b/docs/designs/dom0less-evtchn.md
@@ -0,0 +1,96 @@
+# Signaling support between two domUs on dom0less system
+
+## Current state: Draft version
+
+## Proposer(s): Rahul Singh, Bertrand Marquis
+
+## Problem Statement:
+
+The goal of this work is to define a simple signaling system between Xen guests
+in dom0less systems.
+
+In dom0less system, we cannot make use of xenbus and xenstore that are used in
+normal systems with dynamic VMs to communicate between domains by providing a
+bus abstraction for paravirtualized drivers.
+
+One possible solution to implement the signaling system between domUs is based
+on event channels.
+
+## Proposal:
+
+Event channels are the basic primitive provided by Xen for event notifications.
+An event channel is a logical connection between 2 domains (more specifically
+between dom1,port1 and dom2,port2). They essentially store one bit of
+information, the event of interest is signalled by transitioning this bit from
+0 to 1. An event is an equivalent of a hardware interrupt.
+
+Notifications are received by a guest via an interrupt from Xen to the guest,
+indicating when an event arrives (setting the bit).

I am a bit confused with the description. Are you trying to explain the event 
channel in layman term? If not, then event channel protocol is more complicated 
than that (in particular for fifo).

Yes I am trying to explain the event-channel in simple term.

I would suggest to make that clear and also point to the documentation for the Event Channel ABI (we have a doc for fifo at least).

+
+Event channel communication will be established statically between two domU
+guests before unpausing the domains after domain creation. Event channel
+connection information between domUs will be passed to XEN via device tree
+node.

Why are we limiting ourself to domUs?

As this design is for a dom0less system I mean here to all the domains on the 
dom0less system.
What I understand is that all domains in the dom0less system are called as 
domUs.

It depends on whether an admin may have specific a dom0 kernel. Looking at Penny series to handle shared memory, it will be possible to create a shared region between dom0 and a dom0less domU. Most likely the user will also want to provide a notification communication.

So shouldn't we also provide a way to create an event channel between dom0 and another domU?

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.