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

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

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:

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


Julien Grall

Xen-devel mailing list



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