lkml.org 
[lkml]   [2011]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateTue, 29 Mar 2011 16:19:50 +0100
FromStefano Stabellini <>
SubjectRe: [Xen-devel] [PATCH] xen: do not clear and mask evtchns in __xen_evtchn_do_upcall
On Tue, 29 Mar 2011, Jan Beulich wrote:
> >>> On 29.03.11 at 16:15, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > xen: do not clear and mask evtchns in __xen_evtchn_do_upcall
> >
> > Switch virqs and pirqs that don't need EOI (in Xen acktype ==
> > ACKTYPE_NONE, that means the machine irq is actually edge)
> > to handle_edge_irq.
> >
> > Use handle_fasteoi_irq for pirqs that need eoi (they generally
> > correspond to level triggered irqs), no risk in loosing interrupts
> > because we have to EOI the irq anyway.
> >
> > This change has the following benefits:
> >
> > - it uses the very same handlers that Linux would use on native for the
> > same irqs;
>
> For IO-APIC IRQs this is true, but I don't think it is for MSI.

Yes it is:

static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
int irq)
...
irq_set_chip_and_handler_name(irq, chip, handle_edge_irq, "edge");


> > - it uses these handlers in the same way Linux would use them: it let
> > Linux mask\unmask and ack the irq when Linux want to mask\unmask and ack
> > the irq;
>
> Same here, plus with this you give the change the appearance as
> if Linux now suddenly had control over when the ACK happens,
> which I don't think is the case (and would be wrong in the DomU
> case at least).

From the evtchn perspective, the ack is clearing the pending bit in the
shared_info page, so I think we are giving Linux control on when the ack
happen.
From the pirq perspective, we are giving Linux control on when the eoi
happen.


\
 
 \ /
  Last update: 2011-03-29 17:21    [from the cache]
©2003-2010