Re: [PATCH 5/8] xen/evtchn: don't close the static event channel.

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

> On 28 Jun 2022, at 15:26, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 28/06/2022 14:53, Rahul Singh wrote:
>> Hi Julien
> 
> Hi Rahul,
> 
>>> On 23 Jun 2022, at 4:30 pm, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> 
>>> 
>>> On 23/06/2022 16:10, Rahul Singh wrote:
>>>> Hi Julien,
>>>>> On 22 Jun 2022, at 4:05 pm, Julien Grall <julien@xxxxxxx> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On 22/06/2022 15:38, Rahul Singh wrote:
>>>>>> Guest can request the Xen to close the event channels. Ignore the
>>>>>> request from guest to close the static channels as static event channels
>>>>>> should not be closed.
>>>>> 
>>>>> Why do you want to prevent the guest to close static ports? The problem I 
>>>>> can see is...
>>>> As a static event channel should be available during the lifetime of the 
>>>> guest we want to prevent
>>>> the guest to close the static ports.
>>> I don't think it is Xen job to prevent a guest to close a static port. If 
>>> the guest decide to do it, then it will just break itself and not Xen.
>> It is okay for the guest to close a port, port is not allocated by the guest 
>> in case of a static event channel.
> As I wrote before, the OS will need to know that the port is statically 
> allocated when initializing the port (we don't want to call the hypercall to 
> bind the event channel). By extend, the OS should be able to know that when 
> closing it and skip the hypercall.
> 
>> Xen has nothing to do for close the static event channel and just return 0.
> 
> Xen would not need to be modified if the OS was doing the right (i.e. no 
> calling close).
> 
> So it is still unclear why papering over the issue in Xen is the best 
> solution.

It is not that a static event channel cannot be closed, it is just that during 
a close there is nothing to do for Xen as the event channel is static and hence 
is never removed so none of the operations to be done for a non static one are 
needed (maybe some day some will be, who knows).

Why requiring the OS to have the knowledge of the fact that an event channel is 
static or not and introduce some complexity on guest code if we can prevent it ?

Doing so would need to have a specific binding in device tree (not to mention 
the issue on ACPI), a new driver in linux kernel, etc where right now we just 
need to introduce an extra IOCTL in linux to support this feature.

Cheers
Bertrand