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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 12 May 2022, Rahul Singh wrote:
> > 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

I think that's OK