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

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


  • To: Julien Grall <julien@xxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Thu, 12 May 2022 14:31:15 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • 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=2; 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=7m5ulshnAG3BFpvQEkE8QBtmECw2l2HwJEVbueGS9zg=; b=Hqy3N/J3pxQjHDn9qPaw4iwPyJN7MBU2BzkqS/aIUwgwdyZiqe9A8PBNpPV4YiXiozfd1sKraGbdSOCkve3CdivWZhPcTGR4bW+I6p5RXZZEJ4sx+VGlajX/E2Fw/1w77SzjfNQOTrWW5OaDoezcIUQLkb7V2i5vfYlCxuWXCx7S1QkVeUOm3DEB1lg5QX14/0Mq7iTeDFAG6lk+ATLfL/6XcywHEBUHJD7uKIyGx67iQ6zBYdpQF2OR+rFZ8tD1AhwDw8G2CBM6BsXHciQYPcawQqW2W2r55A6ZTb8TC358RqvY9ZK4qx+ivutiQ4p3y2fKBihasOOJ5W6i5k5z8g==
  • 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=7m5ulshnAG3BFpvQEkE8QBtmECw2l2HwJEVbueGS9zg=; b=GlyntnPpMfQfgD0qqWKRrzvC8kpNl4y06KZkSMNr/s1uo3oLBoeoTNQuwKbYoJBqdpYwUf3SHwRAXHKbwcyC0MGGpdNe4N4Q7f9yhVXxnhkmgB/Qhhx1sZldY5DDj8xpaGi05UrUhLyutCuO/zGRiss4klP3y3SH0NMIz6QGCWr3KIYmRqjKjSkRWkXp92mQdmKHjlR+grhnTnWk67wg5KGXRvaZDXqq4gkogpf3JJ1L/3hNGwim9ibwY7+pFkyavb0zpKmM5RcXY6YHU2iOKgYSsSO0OM5ObHujbICrstETzRlWFoguCKWgrtETDdbmuK3B276tsM3Z4PY1YXeLTg==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=RlOdcCloSCOjoOou6THH8zoA1iFs9Di3n9xSllMk8j+UkV9WVcDOAoDouqdqnlaitJcPngtECXrQhaagThDdiDCXpJ2v5RHl6EAtboo9b4cvtvSRKKMwaxFHDC60Y7pr+0tuBK95W2nBzhglVAVwO1VJWZaghsXH+QCOFdLFcINMLo9JpeldygJzbm4486CP2T4Eqms5tdKx7nOqgJaYYXrnhp1r0ndKEr5vOgu5SfSVOvIQqMD6qZZTeRonVbHmHuDhqSyJJpS4zByHjwL1HXwYNdJPlzf8BPMUx2LYMrUANR/p+ETqV4Yj5LZGR5tjhoeEJkGpOSeKYilYvqnIgA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LHpZMFc4gim3KY3MJ7ANdd3MO4ayKCaxMfTNf0Afzt0uYURH4BLteqhR+Od/uPpYLtOhmbNDgOY2llxZhxCbDGGP8OfBAobwmY1byEl4ktYrO13xSaFqmfYZ38UVkaeMjB4XNykegrztPLjISpR9pTQGr2j7Iz7WjIHLIxkv74yzgjnHrk8R24MO5xstTs63uHrz/ILUA0Csu+a9mlKg/HPdPx/bkcsGuF0ZLy2ZlRWOEkI4WXZ/YMiGsXMKqSUF1NJwfi4ummM+UDcoNzhhFAOq9uuHh7QS+WEKsSEzXp2xbKT0wbZukZzhwH8r5jtQhzxdQ4ekl1dNvPjUhxPMtQ==
  • 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>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 12 May 2022 14:31:38 +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: AQHYX91LOZcKc9ovCE+M72ipF+LMFK0YFGsAgAGzp4CAATSfgIAAXXOA
  • Thread-topic: [PATCH v2] xen/evtchn: Add design for static event channel signaling

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

 


Rackspace

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