lkml.org 
[lkml]   [2019]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Xen-devel] xen/evtchn and forced threaded irq
    From
    Date
    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
    > Cheers,
    >
    >> [1]
    >> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h;h=cc5de9cb1f35dedc99c866d73d086b19e496852a;hb=HEAD#l756
    >>
    >

    \
     
     \ /
      Last update: 2019-02-25 15:08    [W:8.643 / U:0.444 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site