[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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@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, 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |