On Tue, 29 Mar 2011, Jan Beulich wrote:
> >>> On 29.03.11 at 16:15, Stefano Stabellini
> >>> <stefano.stabellini@xxxxxxxxxxxxx> 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,
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
>From the pirq perspective, we are giving Linux control on when the eoi
Xen-devel mailing list