On Thu, 2012-07-12 at 14:16 +1000, Alexey Kardashevskiy wrote: > On 12/07/12 12:54, Alex Williamson wrote: > > On Wed, 2012-07-11 at 12:25 +1000, Alexey Kardashevskiy wrote: > >> On 11/07/12 02:57, Alex Williamson wrote: > >>> On Tue, 2012-07-10 at 15:51 +1000, Alexey Kardashevskiy wrote: > >>>> The two patches in this set are supposed to add VFIO support for POWER. > >>>> > >>>> The first one adds one more step in the initalizaion sequence which I am > >>>> not > >>>> sure is correct. > >>>> > >>>> The second patch adds actual VFIO support. It is not ready to submit but > >>>> ready to discuss. I would like to get rid of all #ifdef TARGET_PPC64 in > >>>> patch #2 > >>>> and I wonder if there is any plan to implement some generic EOI support > >>>> code, etc. > >>> > >>> A generic EOI notifier is on my todo list, but I have no idea what it's > >>> going to look like. As you know, I've got an ioapic specific notifier > >>> in my tree, you add a spapr specific one. I welcome ideas on how to > >>> create something generic that has a chance of being accepted. Thanks, > >> > >> > >> So far the only platform specific call is xxxx_add_gsi_eoi_notifier. The > >> xxxx_remove_gsi_eoi_notifier only calls notifier_remove, you've got to fix > >> yours > >> ioapic_remove_gsi_eoi_notifier() as it does too much :) > >> > >> > >> The only place for placing "add_eoi" callback I can see right now is > >> QEMUMachine as there is no > >> unified machine interrupt controller - IOAPIC has its own type > >> TYPE_IOAPIC_COMMON and XICS is not > >> even a SysBusDevice. And the callback is not specific for any kind of bus > >> so it cannot go to PCIBus. > >> > >> Does it sound reasonable? > > > > I suspect we'd need to somehow tie it into qemu_irq where both handlers > > and notifiers are allocated so we don't really care the underlying > > implementation. Something like qemu_add_irq_eoi_notifier(qemu_irq > > irq, ...). It's another mess like adding the PCIBus interrupt line to > > gsi effort though. Thanks, > > > Tried. Added add_eoi_notifier() callback to qemu_irq, new IRQ allocator: > qemu_irq *qemu_allocate_irqs2(qemu_irq_handler handler, void *opaque, int n, > qemu_eoi_add_notifier add_notifier); > and called it from the XICS initialization code. > > It could work out if pci_get_irq() or pci_route_irq_fn() returned qemu_irq > but no, they just return > a global IRQ number (pure or embedded in a struct) and there is no common way > to resolve qemu_irq > (and then add_eoi_notifier()) from that number within vfio_pci.
Well GSI and qemu_irq are different address spaces. We still need GSI for any kind of qemu bypass case. > May be we could add the callback pointer into PCIINTxRoute? Maybe, but why is this PCI specific? Can't we call it as qemu_add_irq_eoi_notifier(pdev->irq[0], Notifier)? That would work much like qemu_set_irq, extracting the irq number from the IRQState and passing it through to the add_notifier callback for IRQState until it got to the ioapic/pic/xics. int qemu_add_irq_eoi_notifier(qemu_irq *irq, Notifier notifier) { if (!irq || !irq->add_eoi_notifier) return -1; return irq->add_eoi_notifier(irq->opaque, irq->n, notifier); }