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, Alex
