mbox series

[v4,0/7] xen/evtchn: implement static event channel signaling

Message ID cover.1662462034.git.rahul.singh@arm.com (mailing list archive)
Headers show
Series xen/evtchn: implement static event channel signaling | expand

Message

Rahul Singh Sept. 6, 2022, 1:39 p.m. UTC 
The purpose of this patch series is to add the static event channel signaling
support to Xen on Arm based on design doc [1].

[1] https://lists.xenproject.org/archives/html/xen-devel/2022-05/msg01160.html

Julien Grall (1):
  xen/evtchn: Make sure all buckets below d->valid_evtchns are allocated

Rahul Singh (5):
  xen/evtchn: restrict the maximum number of evtchn supported for domUs
  xen/evtchn: modify evtchn_alloc_unbound to allocate specified port
  xen/evtchn: modify evtchn_bind_interdomain to support static evtchn
  xen/arm: introduce new xen,enhanced property value
  xen/arm: introduce xen-evtchn dom0less property

Stanislav Kinsburskii (1):
  xen/evtchn: Add an helper to reserve/allocate a port

 docs/misc/arm/device-tree/booting.txt | 102 ++++++++++++++++
 xen/arch/arm/domain_build.c           | 167 +++++++++++++++++++++++++-
 xen/arch/arm/include/asm/kernel.h     |  23 +++-
 xen/arch/arm/include/asm/setup.h      |   1 +
 xen/arch/arm/setup.c                  |   2 +
 xen/common/event_channel.c            | 121 ++++++++++++-------
 xen/include/xen/device_tree.h         |  16 +++
 xen/include/xen/event.h               |   8 +-
 8 files changed, 387 insertions(+), 53 deletions(-)

Comments

Jan Beulich Sept. 6, 2022, 1:45 p.m. UTC | #1 
On 06.09.2022 15:40, Rahul Singh wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> Since commit 01280dc19cf3 "evtchn: simplify port_is_valid()", the event
> channels code assumes that all the buckets below d->valid_evtchns are
> always allocated.
> 
> This assumption hold in most of the situation because a guest is not
> allowed to chose the port. Instead, it will be the first free from port
> 0.
> 
> When static event channel support will be added for dom0less domains
> user can request to allocate the evtchn port numbers that are scattered
> in nature.
> 
> The existing implementation of evtchn_allocate_port() is not able to
> deal with such situation and will end up to override bucket or/and leave
> some bucket unallocated. The latter will result to a droplet crash if
> the event channel belongs to an unallocated bucket.
> 
> This can be solved by making sure that all the buckets below
> d->valid_evtchns are allocated. There should be no impact for most of
> the situation but LM/LU as only one bucket would be allocated. For
> LM/LU, we may end up to allocate multiple buckets if ports in use are
> sparse.
> 
> A potential alternative is to check that the bucket is valid in
> is_port_valid(). This should still possible to do it without taking
> per-domain lock but will result a couple more of memory access.
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>
> Signed-off-by: Rahul Singh <rahul.singh@arm.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>