|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 7/7] xen/arm: introduce xen-evtchn dom0less property
On Tue, 6 Sep 2022, Rahul Singh wrote:
> Introduce a new sub-node under /chosen node to establish static event
> channel communication between domains on dom0less systems.
>
> An event channel will be created beforehand to allow the domains to
> send notifications to each other.
>
> Signed-off-by: Rahul Singh <rahul.singh@xxxxxxx>
> ---
> Changes in v4:
> - move documentation to common place for evtchn node in booting.txt
> - Add comment why we use dt_device_static_evtchn_created()
> - check if dt_get_parent() returns NULL
> - fold process_static_evtchn_node() in alloc_static_evtchn()
> Changes in v3:
> - use device-tree used_by to find the domain id of the evtchn node.
> - add new static_evtchn_create variable in struct dt_device_node to
> hold the information if evtchn is already created.
> - fix minor comments
> Changes in v2:
> - no change
> ---
> docs/misc/arm/device-tree/booting.txt | 98 +++++++++++++++++
I have just reviewed the binding, only three minor comments below.
Everything looks good.
> xen/arch/arm/domain_build.c | 147 ++++++++++++++++++++++++++
> xen/arch/arm/include/asm/setup.h | 1 +
> xen/arch/arm/setup.c | 2 +
> xen/include/xen/device_tree.h | 16 +++
> 5 files changed, 264 insertions(+)
>
> diff --git a/docs/misc/arm/device-tree/booting.txt
> b/docs/misc/arm/device-tree/booting.txt
> index 1b0dca1454..c8329b73e5 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -382,3 +382,101 @@ device-tree:
>
> This will reserve a 512MB region starting at the host physical address
> 0x30000000 to be exclusively used by DomU1.
> +
> +Static Event Channel
> +====================
> +The event channel communication will be established statically between two
> +domains (dom0 and domU also). Event channel connection information between
> +domains will be passed to Xen via the device tree node. The event channel
> +will be created and established in Xen before the domain started. The domain
> +doesn???t need to do any operation to establish a connection. Domain only
doesn't
better to use ASCII if possible
> +needs hypercall EVTCHNOP_send(local port) to send notifications to the
> +remote guest.
> +
> +There is no need to describe the static event channel info in the domU device
> +tree. Static event channels are only useful in fully static configurations,
> +and in those configurations, the domU device tree dynamically generated by
> Xen
> +is not needed.
> +
> +To enable the event-channel interface for domU guests include the
> +"xen,enhanced = "no-xenstore"" property in the domU Xen device tree node.
double ""
> +
> +Under the "xen,domain" compatible node for domU, there needs to be sub-nodes
> +with compatible "xen,evtchn" that describe the event channel connection
> +between two domUs. For dom0, there needs to be sub-nodes with compatible
> +"xen,evtchn" under the chosen node.
> +
> +The static event channel 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. Maximum supported value is 2^17 for FIFO ABI and 4096 for 2L ABI.
> + It is recommended to use low event channel IDs.
> +
> + link-to-foreign-evtchn is a single phandle to a remote evtchn to which
> + local-evtchn will be connected.
> +
> +Example
> +=======
> +
> +chosen {
> +
> + /* one sub-node per local event channel */
It would be good to say that this is for dom0 in the comment, e.g.:
/* this is for Dom0 */
> + ec1: evtchn@1 {
> + compatible = "xen,evtchn-v1";
> + /* local-evtchn link-to-foreign-evtchn */
> + xen,evtchn = <0xa &ec2>;
> + };
> +
> + domU1 {
> + compatible = "xen,domain";
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + xen,enhanced = "no-xenstore";
> +
> + /* one sub-node per local event channel */
> + ec2: evtchn@2 {
> + compatible = "xen,evtchn-v1";
> + /* local-evtchn link-to-foreign-evtchn */
> + xen,evtchn = <0xa &ec1>;
> + };
> +
> + ec3: evtchn@3 {
> + compatible = "xen,evtchn-v1";
> + xen,evtchn = <0xb &ec5>;
> + };
> +
> + ec4: evtchn@4 {
> + compatible = "xen,evtchn-v1";
> + xen,evtchn = <0xc &ec6>;
> + };
> + };
> +
> + domU2 {
> + compatible = "xen,domain";
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + xen,enhanced = "no-xenstore";
> +
> + /* one sub-node per local event channel */
> + ec5: evtchn@5 {
> + compatible = "xen,evtchn-v1";
> + /* local-evtchn link-to-foreign-evtchn */
> + xen,evtchn = <0xb &ec3>;
> + };
> +
> + ec6: evtchn@6 {
> + compatible = "xen,evtchn-v1";
> + xen,evtchn = <0xd &ec4>;
> + };
> + };
> +};
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |