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

Re: [PATCH 2/8] xen/evtchn: modify evtchn_alloc_unbound to allocate specified port


  • To: Julien Grall <julien@xxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Thu, 28 Jul 2022 15:37:47 +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=NUSvrrqj1h4rtA4Pq/sp6Cnh8ley9aSPxp0ZG0cWosk=; b=Wey519HkBG5pujsqc8Qt0ffIpoqZaUtu+w1iK+SHYOC3gZhWsncsStgxnCE+HaeTWKkh6f0E9j7rm6xa117NGFIXNuYPO4c4DSwG5saSxlPvGPupc14CgLiCHpYRE5YVYuMQWY5hdyw9Ke3EC41bEx46qz3gBVecc5P28Aaw5UXjH2D9LERE5OZWTTZ6kHTJkv19cv34FK1WGOn8ln+en1rETLWvisgqbhGGPaZIhchBpjjFPGvtW9/olxy/P/RKWRC8521evMcUWjF/rt7lnP6qHsxPW45HqXaFYBbhNu+N5GE2g5fDlfsGYTmX6jqnyloa2V1+jxzWphzIPZo1bg==
  • 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=NUSvrrqj1h4rtA4Pq/sp6Cnh8ley9aSPxp0ZG0cWosk=; b=etcNy3al4/GhcmyGeHlo3P/4hxb6XG6jApO3NrnwsVh1Sb6T/Ma+1nk3tZ9Xr1C5IGMaEncblVwUcGLHX4/E/immRAeFNTqr/q8y9+EKpclyYyZ2Eq8zX8ryrsKURPka9GPitrMkP0JuIOGjIalvxv5y8zCYnzVNoJQHyePHO7j0tqs0uFAYKDrUwvzeF4VxKTNpH33Iem1Ls5/qsdm/FC5IMEaKX9rmXREZPUsNkKd9uo8J252VlNK5H+fn0ewkt7hy+U00CoMbwKt8pxURD9ArxolnbU5o0Wp4P0mYVc1n2DLZZqN4+2xakcVRNUpF9+gjJEgJlVHmf8/HsVZaLA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=ElMhYn4mWNtF3SB6IaPLu9MN9yFvJVOrOxx1r/ZJNu4Fwr9CXXxonywp6qTHMyUQyvUtnTNrj5Vmizc2XAKKj64yAkHg1J0K3CyxD+QSgt2ddlHT1Zly98VZpzOpWrVnIPoNexG6XgoYeUVXVHNnnkaICgA1Pzqkgg/IB/E7z5TLTEAYbkAcE3TlgIpds0BguHiQ07ox1WpGRQGYeyMkcSqUNxOfQJbJUlLfGrfjfvkGEp0+4bS6bVKyPi0a+Wew/GHcn8G4aZ682oUjdZE4rvTvNeYydEfabC5B7+D6l2H1bPjxkPoqQU/yy61fjNstlEXHc58UPhRBVL/u4nb/dA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B8w10Ke/oPWpifRh5VgKZAMqKBHGhSBsxJOiDoh4f5sKZ3Bs/1bZUK/rYtUf84uHCW7L6KkdZIIubc0NkuyUUktXLq/8kuA4+Ow+mb7TliF4JqKkhTqDuIJF5gH8AcC/G5aeggnoB0ep1RyzRZ8w/FlsX771rQur90ev2MNbq2JAqP/eKE/CGsZL41/WZxaRl9S6RqlhCldTflfRomxVV8r+BfGhGsXx1AjQeDdOXhe1yy5ldvDCzVChbAtn49ZXVIWuYGYwq4JHjIi71fzhAwAcoHQjTq4+Ea8PwJYUemKuiUJeMjTo5dVyDA3aJcOrg84WAReWBEaJAioTVFMrZw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 28 Jul 2022 15:38:18 +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: AQHYhkXaSSR0QDc2DUiowhnmyNd/Sq1bgqiAgB3xuACAAai8gIAA1/CAgAA2U4CAAAT8AIAABuwAgAAKeYCAAAnjAIAAC4AAgAAEsgCACtZcgIAAFXWAgAGspoCAAAsFgIAAI8AAgAf9PoCAAwMegA==
  • Thread-topic: [PATCH 2/8] xen/evtchn: modify evtchn_alloc_unbound to allocate specified port

Hi Julien

> On 26 Jul 2022, at 6:37 pm, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 21/07/2022 16:37, Rahul Singh wrote:
>> Hi Julien,
> 
> Hi Rahul,
> 
>>> On 21 Jul 2022, at 2:29 pm, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> On 21/07/2022 13:50, Rahul Singh wrote:
>>>> Hi Julien,
>>> 
>>> Hi Rahul,
>>> 
>>>>> On 20 Jul 2022, at 12:16 pm, Julien Grall <julien@xxxxxxx> wrote:
>>>>> 
>>>>> Hi Rahul,
>>>>> 
>>>>> On 20/07/2022 10:59, Rahul Singh wrote:
>>>>>>> On 13 Jul 2022, at 1:29 pm, Julien Grall <julien@xxxxxxx> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 13/07/2022 13:12, Bertrand Marquis wrote:
>>>>>>>>> On 13 Jul 2022, at 12:31, Julien Grall <julien@xxxxxxx> wrote:
>>>>>>>>>> I can't
>>>>>>>>>> see why it would be wrong to have a more tight limit on static ports
>>>>>>>>>> than on traditional ("dynamic") ones. Even if only to make sure so
>>>>>>>>>> many dynamic ones are left.
>>>>>>>>> 
>>>>>>>>> This is similar to Xen forbidding to close a static port: it is not 
>>>>>>>>> the hypervisor business to check that there are enough event channel 
>>>>>>>>> ports freed for dynamic allocation.
>>>>>>>> On other side we need to be cautious not to add too much complexity in 
>>>>>>>> the code by trying to make things always magically work.
>>>>>>>> If you want Xen to be accessible to non expert by magically working 
>>>>>>>> all the time, there would be a lot of work to do.
>>>>>>> 
>>>>>>> It is not clear to me whether you are referring to a developper or 
>>>>>>> admin here.
>>>>>>> 
>>>>>>> On the admin side, we need to make sure they have an easy way to 
>>>>>>> configure event channels. One knob is always going to easier than two 
>>>>>>> knobs.
>>>>>>> 
>>>>>>> On the developper side, this could be resolved by better documentation 
>>>>>>> in the code/interface.
>>>>>>> 
>>>>>>> Cheers,
>>>>>> To conclude the discussion, If everyone agree I will add the below patch 
>>>>>> or similar in the next version to restrict the
>>>>>> max number of evtchn supported as suggested.
>>>>> 
>>>>> I am fine if the limit for domU is fixed by Xen for now. However, for 
>>>>> dom0, 4096 is potentially too low if you have many PV drivers (each 
>>>>> backend will need a few event channels). So I don't think this wants to 
>>>>> be fixed by Xen.
>>>> Agree.
>>>>> 
>>>>> I am not entirely sure we want to limit the number of event channels for 
>>>>> dom0. But if you want to, then this will have to be done via a command 
>>>>> line option (or device-tree property).
>>>> We need to support the static event channel for dom0 also, in that case, 
>>>> we need to restrict the max number of evtchn for dom0 to mitigate the 
>>>> security issue.
>>> 
>>> It sounds like there are some misundertanding or I am missing some context. 
>>> The static event channels will be allocated at boot, so the worse that can 
>>> happen is it will be slower to boot.
>>> 
>>> My point regarding fifo was more in the generic case of allowing the caller 
>>> to select the port. This would be a concern in the context of 
>>> non-cooperative live-migration. An easy way is to restrict the number of 
>>> ports. For you, this is just an increase in boot time.
>>> 
>>> Furthermore, there is an issue for dom0less domUs because we don't limit 
>>> the number of port by default. This means that a domU can allocate a large 
>>> amount of memory in Xen (we need some per-event channel state). Hence why I 
>>> suggested to update max_evtchn_channel.
>> Thanks for the clarification.
>>> 
>>>> If the admin set the value greater than 4096 (or what we agreed on) and 
>>>> static event channel support is enabled we will print the warning to the 
>>>> user related to fill
>>>> the hole issue for FIFO ABI.
>>> 
>>> See above. I don't see the need for a warning. The admin will notice that 
>>> it is slower to boot.
>> Ok. I will not add the warning. Just to confirm again is that okay If I add 
>> new command line option "max_event_channels” in
>> next version for dom0 to restrict the max number of evtchn.
> 
> Personally I am fine with a command line option to *globally* restrict the 
> number of events channel. But Jan seemed to have some reservation. Quoting 
> what he wrote previously:
> 
> "Imo there would need to be a very good reason to limit Dom0's port range.

As you mentioned, if we don’t restrict the number of events channel for the 
dom0 system will boot slower.
This is a good reason to restrict the number of event channels for dom0.
 
@Jan: I need your input on this before I send the next version of the patch 
series.

Regards,
Rahul

 


Rackspace

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