[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: David Vrabel <dvrabel@xxxxxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Mon, 11 Apr 2022 16:01:45 +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=OIO6EzaPgN5Wx9Dx6ReWJ5NqmFLU9C89nzEVqcF4ays=; b=izP5UexVHDY1n7Y0Jhv1Gteb8n+AKlHTt3O+ghHoKnDTr4UhQSZf3pGaBgqMBIJCZ5+8ohc6Gf1RyzqwnVh3BLwpg7w/JjQiakTvZhcmggOCmkLcnKRAmb+/RZxLqfGLnC6U2LRL2Syhc4MBj4s7tt+ksA4/hXmgHcznv/vMnF26AdQAQx14DYc8G5qjVFV5FOsy7bsPmC0oG0jZS+iKgiSVATRKKu1eP4z5EPJv5OP/mgUl4cY3C5GLx9GxlEFcclBHLU4Kh88RTMlh89XHBvr5CNXkQfhroWG7uerqWVmLtfTx+mjPp/hIh06aTSb6kf7BfEwRpxO/6PxczTdcHA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJOUw7aTcZUPekfdhW9OgrnId1XDmjPJmAAcHhr3LxcP2ZvixPc0MqXCQVpyA5i8Qu1b4q5UFHYsJ80F9SL04emWDT6PSP1YF0NUPyEwhjzrryDH85Ik/UnoeRdHJagry8fZ/bq2XoKNRJBpbpx2IjAGTeUFt8q5RVqeJ7Kiq0anc/V+4PS1U50PPmKpN4DXaf1ibH6Dkec01w2EwwgIrfMVI1sptFTmcbjD7NFuvwiXGuDqvvVvwuSkFQY71rZ28Cvdn21VSAbJ/IEDIzRAYsG53HHGEpF/k9vj7ctmv7Ru727ejAsjFZYhjRMa99VY7k1tpKEYmx1nE/D/oMVkZw==
  • 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>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 11 Apr 2022 16:02:20 +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: AQHYPsy9MfyfmFhecEGJuSNYyusIgKzOdqoAgByGnQA=
  • Thread-topic: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hello David,

Thanks for reviewing the design and sorry for the late reply. 

> On 24 Mar 2022, at 12:24 pm, David Vrabel <dvrabel@xxxxxxxxxx> wrote:
> 
> 
> 
> On 23/03/2022 15:43, Rahul Singh wrote:
>> in dom0less system. This patch introduce the new feature to support the
>> signaling between two domUs in dom0less system.
>> 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.
> 
> This problem statement could do with some example use cases that are usefully 
> solved by this proposed solution.
> 
> "We don't have xenstore so can't set up shared rings, but here's a 
> replacement comms mechanism that can do a single bit." Doesn't seem very 
> compelling to me.

Ok. Let me add more information in next version.
> 
>> + chosen {
>> + ....
>> +
>> + domU1: domU1 {
>> + ......
>> + };
>> +
>> + domU2: domU2 {
>> + ......
>> + };
>> +
>> + evtchn@1 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xa &domU1 0xb &domU2>;
>> + };
>> +
>> + evtchn@2 {
>> + compatible = "xen,evtchn";
>> + xen,evtchn = <0xc &domU1 0xd &domU2>;
>> + };
> 
> How is the domain supposed to know what these event channels are for?

As we are statically defining the event channel in XEN, we can document the 
event
channel connection information for the end-user in the end-user documentation 
and
let the user decide how he is going to use it.  

> 
> I'm not that familiar with device tree. Is it possible to give these entries 
> name?

As per the device-tree specification, each node in the device tree is named 
according to the following convention
        node-name@unit-address

We can give the name to these entries but in another email, we are discussing 
having singe node, in that
case there is no need to give a name.

evtchn {
        compatible = "xen,evtchn-v1”;
        xen,evtchn = <0xa &domU1 0xb &domU2 0xc &domU1 0xd &domU2>;
};

Regards.
Rahul
> 
> David


 


Rackspace

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