On 20.07.2022 13:16, Julien Grall wrote:
> On 20/07/2022 10:59, Rahul Singh wrote:
>>> On 13 Jul 2022, at 1:29 pm, Julien Grall <jul...@xen.org> wrote:
>>> On 13/07/2022 13:12, Bertrand Marquis wrote:
>>>>> On 13 Jul 2022, at 12:31, Julien Grall <jul...@xen.org> 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.
> 
> 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).

Imo there would need to be a very good reason to limit Dom0's port range.

Jan

Reply via email to