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

Re: [PATCH v2 3/7] xen/evtchn: restrict the maximum number of evtchn supported for domUs


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 23 Aug 2022 11:44:20 +0000
  • Accept-language: en-GB, 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=BfxdHKoHV8fwfMe9Cjjf9wTxPXTOVIcmXr6zf3L9YDk=; b=kI4t+EpEd3d2hbu4xymsxp8qS+n7ITEvQZZGyYhZXTeo40BZ8fRqAeYMI/YbJrisPtjCzdhw387+kdv22h7RFOcu204xo28w+mmjtpjJ+Tu7viWZSORihCqlyY9nTL3u6cCqro/3Eh+avJM7gWQGtDVQOlBrjrJuIpychiPb7E1/JvWRy33jhLfGkDCIdwbR9gI3pfKtw4Cz1/Fku5cRlAwiSb1UkSsgByelAPWrkat8SLmmEKx844S0YIx4svqFQijRY2AUeTCKdxwU9FerhUJoixleQy6VqsvAtlozUv1hU/Nmdxe+PLQ34SwvOnt4w1Uwamm2psA1dDkwpPd08A==
  • 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=BfxdHKoHV8fwfMe9Cjjf9wTxPXTOVIcmXr6zf3L9YDk=; b=hbnkzBaSrfAtfDmM3sBUtiOXh57N6/r573p3iFDbtc2Xz4o6IffCwAKUpL6j5zinWK16+0UbiJ1j7x5ReVisbIswqzcL5ZDTRZZ62v88XSdzkycxXKjgGKY5rWrJQlsUvMPb62yELeqquU7eSpbc33IeSkcuumbUkxeNvWxurNKdez1GzLzosb8ckAwaWvbDtBr8ndLOTaPzTcd9L4/Oegt2dFTx0VA7kJxYzoSigM/IxBtETffoB/esFK6zsY0LCh5IVGsCVHdjMTJuIo1dnWeWhJLYSVIT03EbS7ZGnqOmZKNC2AAWLsRDWz1V/SfOGHakPelbp2G9DKsC5AWzew==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=KG/ViuFOzWJyWPRFOrarU7ZZRNcXZgdqCQsZcuAfk/Wlk8jrEHz/XRWtDPVs66tNlt5JbVtvNQ7WwXvJP4F0P0ZEEcdzEHHinni9T1cXo/iWWNNeJc2mbme2IybPv44Dh8p/2QQciDvJr5UW/Tx6qCGw6bgzTkU+Z9UZX3YuH+wkuBu81Yml0BY59WR9qN+BYt9Xy/ItcHK8oQikQeU3WoPPvhLNkqqyWIkZGPTvk1g734N9cO0MVWXayzS+1L+/78iYvvS5JQI8OtqwUZqiWG+4lAfX2YhwB6j9ou/FSBhGr5OXkUwHkTekV82vQRLur8kvhFUEmKpB3PLuFUTFvA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qy3x5xwQdqX3QeW/rUNd7tyMQ7OFENhJdnCEPr7GRtGZZN3sfPWm7zLxHtm/cJQJoZKS6Vi0C5Y3MjgETci2BKLyK6uI681HTbPzVgU4JlmlGV1PAU9vPUxIEOS4EK423FJ50rtg8l1W/NRlKqOgXln5UgpoP/nl5rypLn0zQ9abJdsUjtTfhkYvX4+YNSYWHMdZxHneYKnSacRlyjBwt4fXzIE6HEstEUd3rFnpU/ekxBVvA9RPfkmY83OfAdGAZ6De0c+jhAfrwv91bNJs3sMNmlVMGsCR8Wz6h8HtYw00czHydpb0yWcEtPBtdvKVrTnc2MmG+R1oVjLRyDVLGQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Rahul Singh <Rahul.Singh@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 23 Aug 2022 11:44:54 +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: AQHYs7MV2LzwQkpIc0uI74Vj50Jrma269JmAgAEvmICAAAk5AIAAJFSAgAAPtwCAAAKAgA==
  • Thread-topic: [PATCH v2 3/7] xen/evtchn: restrict the maximum number of evtchn supported for domUs

Hi Jan,

> On 23 Aug 2022, at 12:35, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 23.08.2022 12:39, Rahul Singh wrote:
>> Hi Jan,
>> 
>>> On 23 Aug 2022, at 9:29 am, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 23.08.2022 09:56, Julien Grall wrote:
>>>> On 22/08/2022 14:49, Jan Beulich wrote:
>>>>> On 19.08.2022 12:02, Rahul Singh wrote:
>>>>>> --- a/xen/arch/arm/domain_build.c
>>>>>> +++ b/xen/arch/arm/domain_build.c
>>>>>> @@ -3277,7 +3277,7 @@ void __init create_domUs(void)
>>>>>>         struct xen_domctl_createdomain d_cfg = {
>>>>>>             .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
>>>>>>             .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
>>>>>> -            .max_evtchn_port = -1,
>>>>>> +            .max_evtchn_port = MAX_EVTCHNS_PORT,
>>>>>>             .max_grant_frames = -1,
>>>>>>             .max_maptrack_frames = -1,
>>>>>>             .grant_opts = 
>>>>>> XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
>>>>>> --- a/xen/include/xen/sched.h
>>>>>> +++ b/xen/include/xen/sched.h
>>>>>> @@ -76,6 +76,9 @@ extern domid_t hardware_domid;
>>>>>> /* Maximum number of event channels for any ABI. */
>>>>>> #define MAX_NR_EVTCHNS MAX(EVTCHN_2L_NR_CHANNELS, 
>>>>>> EVTCHN_FIFO_NR_CHANNELS)
>>>>>> 
>>>>>> +/* Maximum number of event channels supported for domUs. */
>>>>>> +#define MAX_EVTCHNS_PORT 4096
>>>>> 
>>>>> I'm afraid the variable name doesn't express its purpose, and the
>>>>> comment also claims wider applicability than is actually the case.
>>>>> It's also not clear whether the constant really needs to live in
>>>>> the already heavily overloaded xen/sched.h.
>>>> 
>>>> IMHO, I think the value would be better hardcoded with an explanation on 
>>>> top how we chose the default value.
>>> 
>>> Indeed that might be best, at least as long as no 2nd party appears.
>>> What I was actually considering a valid reason for having a constant
>>> in a header was the case of other arches also wanting to support
>>> dom0less, at which point they likely ought to use the same value
>>> without needing to duplicate any commentary or alike.
>> 
>> 
>> If everyone is  okay I will modify the patch as below:
> 
> Well, I'm not an Arm maintainer, so my view might not matter, but
> if this was a change to code I was a maintainer for, I'd object.
> You enforce a limit here which you can't know whether it might
> cause issues to anyone.

The limit was agreed and discussed between him and Julien and
I agree with them (if any more views were required).

Not quite sure if your mail was to request an other maintainer to
confirm but done anyway.


Bertrand


> 
> Jan
> 
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 3fd1186b53..fde133cd94 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -3277,7 +3277,13 @@ void __init create_domUs(void)
>>         struct xen_domctl_createdomain d_cfg = {
>>             .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
>>             .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
>> -            .max_evtchn_port = -1,
>> +            /*
>> +             * The default of 1023 should be sufficient for domUs guests
>> +             * because on ARM we don't bind physical interrupts to event
>> +             * channels. The only use of the evtchn port is inter-domain
>> +             * communications.
>> +             */
>> +            .max_evtchn_port = 1023,
>>             .max_grant_frames = -1,
>>             .max_maptrack_frames = -1,
>>             .grant_opts = XEN_DOMCTL_GRANT_version(opt_gnttab_max_version),
>> 
>> Regards,
>> Rahul




 


Rackspace

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