The imposed limit of 1023 is too low for a three digit value of vcpus.
Remove the arbitrary value of 1023 and let Xen decide about the upper limit.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
 docs/man/xl.cfg.5.pod.in   | 8 +++-----
 tools/libxl/libxl_create.c | 2 +-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 0e9e58a41a..ac3fe5f35a 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -1332,11 +1332,9 @@ L</vuart="uart"> to know how to enable vuart console.
 Limit the guest to using at most N event channels (PV interrupts).
 Guests use hypervisor resources for each event channel they use.
 
-The default of 1023 should be sufficient for typical guests.  The
-maximum value depends on what the guest supports.  Guests supporting the
-FIFO-based event channel ABI support up to 131,071 event channels.
-Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
-x86).
+The maximum value depends on what the guest supports.  Guests supporting the
+FIFO-based event channel ABI support up to 131,071 event channels.  Other
+guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit x86).
 
 =item B<vdispl=[ "VDISPL_SPEC_STRING", "VDISPL_SPEC_STRING", ...]>
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e7cb2dbc2b..17c128bc07 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -226,7 +226,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
             b_info->iomem[i].gfn = b_info->iomem[i].start;
 
     if (!b_info->event_channels)
-        b_info->event_channels = 1023;
+        b_info->event_channels = -1U;
 
     libxl__arch_domain_build_info_setdefault(gc, b_info);
     libxl_defbool_setdefault(&b_info->dm_restrict, false);

Olaf Hering writes ("[PATCH v1] libxl: remove limit for default number of event channels"):
> The imposed limit of 1023 is too low for a three digit value of vcpus.
> Remove the arbitrary value of 1023 and let Xen decide about the upper limit.

This seems likely to be right, but: what is the default in Xen ?  Is
it sufficiently tight to stop a guest using too many resources ?

Ian.

On Fri, Mar 27, Ian Jackson wrote:

> This seems likely to be right, but: what is the default in Xen ?  Is
> it sufficiently tight to stop a guest using too many resources ?

The value of d->max_evtchns will be either 4k or 128k.
AFAICS no extra resources are allocated with the changed value.

Olaf

On 27.03.2020 15:37, Olaf Hering wrote:
> On Fri, Mar 27, Ian Jackson wrote:
> 
>> This seems likely to be right, but: what is the default in Xen ?  Is
>> it sufficiently tight to stop a guest using too many resources ?
> 
> The value of d->max_evtchns will be either 4k or 128k.
> AFAICS no extra resources are allocated with the changed value.

Of course there are, as soon as the guest uses the event channels.
Did you see Jürgen's patch sent earlier this week, aiming to
address the same issue of larger vCPU counts being a problem
("tools/libxl: make default of max event channels dependant on
vcpus")? See the discussion there.

Jan

Hi,

On 27/03/2020 14:37, Olaf Hering wrote:
> On Fri, Mar 27, Ian Jackson wrote:
> 
>> This seems likely to be right, but: what is the default in Xen ?  Is
>> it sufficiently tight to stop a guest using too many resources ?
> 
> The value of d->max_evtchns will be either 4k or 128k.
> AFAICS no extra resources are allocated with the changed value.

Event channels are allocated using buckets. Everytime you will a bucket, 
a new bucket will be allocated.

By increasing the limit, you effectively increase the number of buckets 
than can be allocated.

So while I agree that the default allocation will be the same, you 
effectively allow the guest to use more resource in Xen. Therefore I 
don't think this is acceptable to lift the limits for all the guests.

Cheers,

-- 
Julien Grall