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

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

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

[1] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h;h=cc5de9cb1f35dedc99c866d73d086b19e496852a;hb=HEAD#l756

Xen-devel mailing list



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