[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, 21 Jul 2022 15:37:39 +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=ghJcKzz8onE9Vr5Ev7HNN7ipqiTT42ctbkRbF9KRJPI=; b=RTWuUf/hsSeUXCKlVyyVOqo36Z8ekR4scfPlJToAC20JHUqUytw3aDFptNMiEc6j/Fkndi4xQuL9gD92ef4gc+K2KIgZ0okcLf/FU7g7cnB34VcKC4voG/p6W6pE61W0QncWJ72by2c+CoIuF+dCNNEJyrG2PPwUJcijRosGuNdzHO45yd4P7cmKeUZIPuqv3st5mZzAQg4JT79XoYhuZjOpOcVUd1vnrwqsy6YmxzHoXJH9GcbcfCUbPrFQ+OeM67ddJgh4M22m1EiToczPkMLiZiQcRSw6b5YQfr0tIygaEQXu3Qg/xaihhVw/ycZDqjGdKy7JD2Ep9fhR+umoEA==
  • 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=ghJcKzz8onE9Vr5Ev7HNN7ipqiTT42ctbkRbF9KRJPI=; b=NG05nCQc4aqTuLPfG52GDDh753pRFBDgBtxbPoIhPf1UI1jFbULWtnDU8/IRyV8EdJy6VQSeHxSC01L/fKBpoTYBsmJy40RAc0p1f+1ivySwj/8YCUCQ1unUnMmg/oCSnFX4w2mfLvkdztrvv4xStNf6aaqb3etvlfJXS6jtOJzfPe0oL1NvfYxXDw2CuBW42v/RcTP7KNkWU/cdoPaX232Jw0FU9IGmyBj675wQU80ltNix59rJA1NKVgwpxuzPLoa9gJ4jTGbdPa8Hmd2YSS97GprbQv+GovEguvxW6kLpnixj6ix1jUipIKTBNMlQjeb/TiJ2aK+desNisqczgg==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=ZdUQE9JF2kWzGremfRZWJq6XQ9sOQ+rQSt7hgL9tzYdhNhHORmmTWMgTqcWpceJRKRFsVhMl6/AzHAfIP5KuKls3m7w1iumEcL9oI9T9r1NEiVWWmcEJylS22Et/y5kYbOLEsGJj+xznEx1g5UCeNe4TdhgsqU7of13Tri4assQqrw/oc9fP6g8Y+5lWm9XnhSrE/sVSDwifBWJWrtOfvGgmFRNafrpjOOgUFg9Ua9aam3+t//AkzsR0MRtXSel94hVBE7oRqkYzLpBvXbuN0PNV9P+BAgGq7wOK5jaTqQ59x2IfjVrH+e4nxg65KbTG4a5uDzAf5EpsGTxtPM6IsQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eUDPRLDPtC4RCUj1MOWiGBQXLCmGyrVN9QFXQYAcqtNmfc4oUez0U3Xeox/8Beq5xu7Tdxw7fmfx7Mt2gpxpNA8BI7R0AGFKXJhixDk+aSBTKmocoCzqrOIk3DAmjWKfGRb4iiHk3FL2lJjTm7LE9AoSLeIHzyJprs2X8lw9kA8surXgt4Kv0MUbuh4ZA98BHeMA5uv5poJvBIZOWfu7/cw82KkQcSdrL5E3pZKAPEmi7PzxAwiFd1Fnyw9F4byuNQsaZYOoulLymZOc4VtWVNM4SiFf1KfKDYxsKk6enUQrjWbZTQZIPSC8GguSGdUV9rtvanXWDa9IhkxF5hVokA==
  • 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, 21 Jul 2022 15:38:16 +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/CAgAA2U4CAAAT8AIAABuwAgAAKeYCAAAnjAIAAC4AAgAAEsgCACtZcgIAAFXWAgAGspoCAAAsFgIAAI8AA
  • Thread-topic: [PATCH 2/8] xen/evtchn: modify evtchn_alloc_unbound to allocate specified port

Hi Julien,

> 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.

Regards,
Rahul

 


Rackspace

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