Hello David,
Thanks for reviewing the design and sorry for the late reply.
> On 24 Mar 2022, at 12:24 pm, David Vrabel <dvra...@cantab.net> 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.si...@arm.com>
>> ---
>> 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
