[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..


  • To: Julien Grall <julien@xxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Wed, 13 Apr 2022 08:25:48 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D7nhm16zvpEznUQS8UGJAuenc1laUi2B+9iJ9ATqBwY=; b=H7C6pN83GC66H1fxKnGLyTsIygVd8vsZ2pEGJVAqnNnUNAkybeU6SEhHSBFOigvUEDTPkf2x++kWNpB5LcFnq/z7MJrTjgv19p+khLyD+HDXlHgQjHJpp2412JDVS+DEYsaW5NdvvnoMuvflN0rPxIx6dx9ni9l8X5TtK8Tbb1CRPDxqUa6B3Bu/X5ZoYw4r/fBnb3jGvPR8Jr4/k7M9R8MKzXJjCFqo22nLFM2fsakyqZvaco43M0OZNLUm1gKoA83Rs2zwV3PojW08jeLCw8MYYXK3dbol7iREiqOWPa9H7xrFwonK5LMtN9GGL0RPl8E93/CRnirdSZG6W9CmWg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l9Xb2OAuOo1s2m/hDccjAQ2epOgLSm2fb29csUbrqmXa8Mg4n6jn5zXYReGIghrKzQrtvybLiV018ZoI/Kb05gQztogixeLnWYy6M9tSp3myMOp+jZTmE+zq8QI9H6f4e6xG5DeC4pPJ9bopKtWALP+P4OmoOlB9MqDEK8aP+RgXDl5sgdJO9+tltE5D7NOcDPF5sWNilpDi6TFqW5mohSkz4i/810c9pVYQ3rhBt/OduQWEfsx+e6VBQBGARcfgZ45X6FCWkHHmG/HNNDQ/Iu0+PSjJVe3OxRZt+qwDXxTYkLV8jCH0vahiEXrk+rVy/h4trzulqSvhs+bkccwxtQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 13 Apr 2022 08:26:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYPsy9MfyfmFhecEGJuSNYyusIgKzrHq6AgAKD34A=
  • Thread-topic: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hello Julien,

Thanks for reviewing the design.

> On 11 Apr 2022, at 7:01 pm, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Rahul,
> 
> Title: s/../.../
> 
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
> 
> s/introduce/introduces/
> s/the new/a/

Ack. 
> 
>> signaling between two domUs in dom0less system.
> Did you intend to add a newline before the second sentence?

No. I will fix this.

> 
>> 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. 
> 
>> Further notifications are
>> +masked until the bit is cleared again.
> 
> I think "masked" is confusing here.
> 
> The event channel differentiate "mask" vs "pending". When sending an event, 
> the pending bit will be set to 1. If it wasn't already pending and the mask 
> bit is clear, then we will notify the guest.
> 
> If the pending bit is already set, then we will ignore.
> 
> In fact, the event channel is acting similarly to an edge interrupt. I wrote 
> similarly, because IIRC they are behaving slightly differently (see [1] for 
> more details).

Ok. Let me modify the sentence in next version.
> 
>> When a domain wants to wait for data it
>> +will block until an event arrives, and then send an event to signal that 
>> data
>> +has been consumed.
>> Events are delivered asynchronously to guests and are
>> +enqueued when the guest is not running.
> 
> s/guest/domain/ to stay consistent and also include dom0/hardware domain.
Ack.
> 
>> +
>> +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.
Please correct me if I am wrong.

> 
>> +
>> +Under the /chosen node, there needs to be sub nodes with compatible
>> +"xen,evtchn" that descibes the event channel connection between two domUs.
> 
> s/descibes/describes/

Ack. 

> 
>> +
>> +The event channel sub-node has the following properties:
>> +
>> +- compatible
>> +
>> + "xen,evtchn"
>> +
>> +- xen,evtchn
>> +
>> + The property is four numbers of tuples of
>> + (local-port-domU1,domU1-phandle,local-port-domU2,domU2-phandle) where:

> This is quite difficult to read. Can we add some space before/after each 
> comma?

Ack. 
> 
>> +
>> + local-port-domU1 is an integer value that will be used to allocte local
> 
> s/allocte/allocate/

Ack. 
> 
>> + port for domU1 to send an event notification to the remote domain.
> 
> The port will be used for sending but also receiving event notification.

Yes. I will modify.
> 
> Also, I would suggest to replace "remote domain" with "domU2". So it is more 
> explicit.

Ack. 
> 
>> +
>> + domU1-phandle is a single phandle to an domain to which local-port-domU1
> 
> s/an domain/a domain/ I think.

Ack. 
> 
>> + will be allocated.
>> +
>> + local-port-domU2 is an integer value that will be used to allocte local
> 
> s/allocte/allocate/

Ack. 
> 
>> + port for domU2 to send an event notification to the remote domain.
> 
> Same as above for "remote domain".

Ack.  

Regards,
Rahul


 


Rackspace

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