qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 0/2] RFC: powerpc-vfio: adding support


From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH 0/2] RFC: powerpc-vfio: adding support
Date: Thu, 12 Jul 2012 14:16:22 +1000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.

May be we could add the callback pointer into PCIINTxRoute?


-- 
Alexey





reply via email to

[Prev in Thread] Current Thread [Next in Thread]