[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

+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 :).

Cheers,

--
Julien Grall



 


Rackspace

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