Re: [Xen-devel] xen/evtchn and forced threaded irq

[Julien Grall <julien.grall@arm.com>]

Hi Oleksandr,

On 25/02/2019 14:08, Oleksandr Andrushchenko wrote:
> On 2/25/19 3:55 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
>>> On 2/22/19 3:33 PM, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
>>>>> On 2/20/19 10:46 PM, Julien Grall wrote:
>>>>>> Discussing with my team, a solution that came up would be to introduce one 
>>>>>> atomic field per event to record the number of event received. I will 
>>>>>> explore that solution tomorrow.
>>>>> How will this help if events have some payload?
>>>>
>>>> What payload? The event channel does not carry any payload. It only notify 
>>>> you that something happen. Then this is up to the user to decide what to you 
>>>> with it.
>>> Sorry, I was probably not precise enough. I mean that an event might have
>>> associated payload in the ring buffer, for example [1]. So, counting events
>>> may help somehow, but the ring's data may still be lost
>>
>> From my understanding of event channels are edge interrupts. By definition, 
>> they can be merged so you can get a signal notification to the guest for 
>> multiple "events". So if you rely on the event to have an associated payload, 
>> then you probably have done something wrong in your driver.
>>
>> I haven't implemented PV drivers myself, but I would expect either side to 
>> block if there were no space in the ring.
>>
>> What do you do in the displif driver when the ring is full?
>>
> It is handled by the originator, the display backend in our case: it doesn't send
> events if it sees that the ring will overflow. But I was worried about
> such a generic change with counting number of events received and if this
> really helps to recover in general case

Well, I was originally looking at modifying only the /dev/evtchn driver but it 
turns out the event flow for Xen irqchip is not entirely correct.

A lot of Xen PV drivers will thread the handler and set IRQF_ONESHOT expecting 
the event to be masked until the event handler has ran. However, the flow we use 
does not deal with it and actually warn you may receive another event before 
executing the handler for the first event.

I have discussed with Marc Z. (one of the irqchip maintainers) about the issue. 
He suggested a different interrupt flow that I need to try out.

Cheers,

-- 
Julien Grall