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

[Rahul Singh <Rahul.Singh@xxxxxxx>]

Hi Julien,

> On 12 May 2022, at 9:56 am, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Rahul,
> 
> On 11/05/2022 15:32, Rahul Singh wrote:
>>> On 10 May 2022, at 1:32 pm, Julien Grall <julien@xxxxxxx> wrote:
>>>> +domain may toggle masked bits in the masked bit field and should clear the
>>>> +pending bit when an event has been processed
>>>> +
>>>> +Events are received by a domain via an interrupt from Xen to the domain,
>>>> +indicating when an event arrives (setting the bit). Further notifications 
>>>> are
>>>> +blocked until the bit is cleared again. Events are delivered 
>>>> asynchronously to
>>>> +a domain and are enqueued when the domain is not running.
>>>> +More information about FIFO based event channel can be found at:
>>> 
>>> I think the explanation is fine for a design proposal. If you want to use 
>>> it as documentation, then I would suggest to clarify there are two 
>>> different ABI for event channel: FIFO and 2L.
>>> 
>>> 2L is the easiest one to implement and for embedded we may want to steer 
>>> the users towards it.
>> I will rephrase the sentence as below:
>> Xen supports two different ABI for event channel FIFO and 2L. More 
>> information about FIFO based event channel can be found at:
> 
> I think it is a bit strange to point to the FIFO doc but not the 2L (the 
> explanantion above is not really for 2L). If there are no doc for the latter, 
> then I would possibly drop the link.

Ack.

> 
>>>> +The event channel sub-node has the following properties:
>>>> +
>>>> +- compatible
>>>> +
>>>> + "xen,evtchn"
>>>> +
>>>> +- xen,evtchn
>>>> +
>>>> + The property is tuples of two numbers
>>>> + (local-evtchn link-to-foreign-evtchn) where:
>>>> +
>>>> + local-evtchn is an integer value that will be used to allocate local port
>>>> + for a domain to send and receive event notifications to/from the remote
>>>> + domain.
>>> Port 0 is reserved and both FIFO/2L have limit on the port numbers.
>>> 
>>> I think we should let know the users about those limitations but I am not 
>>> sure whether the binding is the right place for that.
>> If you are okay I can add this limitation in this design doc.
> 
> Design docs are generally for developper of Xen rather than the end users. I 
> am OK if you want to add the limitations in this design doc so long we have 
> another easy way for the user to find out the limits.
> 
> This could be end users documentation and/or message in Xen. Note that 2L has 
> a lower limit and we don't know in advance what the guest will use. So we may 
> have to assume the lower limit (4096) which should be plenty for embedded :)

I am planning to explain the static event-channel subnode in 
"docs/misc/arm/device-tree/booting.txt” [1]. I will include the limitation also 
at the same time.

@Stefano:  I need confirmation from you also, is that okay to add new property 
value  "xen,enhanced = evtchn” to only 
enable event-channel interface for dom0less domUs. make_hypervisor_node() will 
set the evtchn PPI interrupts  property only if "xen,enhanced = evtchn” is set.

If "xen,enhanced" with an empty string (or with the value "enabled”) is set 
make_hypervisor_node() will set the grant table, extended region and PPI 
interrupt property.
 
[1] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=7b4a29a2c293d16e9280a24789bc3b5262a367f6;hb=HEAD#l238

Regards,
Rahul