On 24/04/2015 13:59, Eric Auger wrote:
> > Then I would go for the other solution (the notifier, just adding the
> > callback to SysbusDeviceClass). But I still do not understand why you
> > didn't have exactly the same problem :) unless you were walking the list
> > to find the relevant VFIOINT
On 04/24/2015 12:02 PM, Paolo Bonzini wrote:
>
>
> On 24/04/2015 11:48, Eric Auger wrote:
What did the notifier code look like with your patch?
>> Currently both notifiers are stored in the VFIOINTp struct. They are
>> initialized in vfio_init_intp. VFIO platform device holds a list of
>> VF
On 24/04/2015 11:48, Eric Auger wrote:
>> > What did the notifier code look like with your patch?
> Currently both notifiers are stored in the VFIOINTp struct. They are
> initialized in vfio_init_intp. VFIO platform device holds a list of
> VFIOINTp struct.
>
> When the vfio_start_irqfd callback
On 04/24/2015 11:29 AM, Paolo Bonzini wrote:
>
>
> On 24/04/2015 11:18, Eric Auger wrote:
>> I implemented this alternative but my concern is the check method is
>> called before the qemu_irq setting. So on this callback I cannot
>> retrieve the qemu_irq VFIOINTp struct container obje
On 24/04/2015 11:18, Eric Auger wrote:
>>> >> I implemented this alternative but my concern is the check method is
>>> >> called before the qemu_irq setting. So on this callback I cannot
>>> >> retrieve the qemu_irq VFIOINTp struct container object needed to setup
>>> >> irqfd hence does not work
On 04/24/2015 11:11 AM, Paolo Bonzini wrote:
>
>
> On 24/04/2015 11:01, Eric Auger wrote:
void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p)
{
SysBusDeviceClass *sdc = SYSBUS_DEVICE_GET_CLASS(dev);
qdev_init_gpio_out_named(DEVICE(dev), p, SYSBUS_DEVICE_GPIO_IRQ, 1,
>
On 24/04/2015 11:01, Eric Auger wrote:
>> > void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p)
>> > {
>> > SysBusDeviceClass *sdc = SYSBUS_DEVICE_GET_CLASS(dev);
>> > qdev_init_gpio_out_named(DEVICE(dev), p, SYSBUS_DEVICE_GPIO_IRQ, 1,
>> > sdc->irq_set_hook)
On 04/23/2015 11:58 AM, Paolo Bonzini wrote:
>
>
> On 23/04/2015 11:40, Eric Auger wrote:
Why can't you just use a GHashTable?
>> You mean implementing this hash table in the interrupt controller?
>
> No, in KVM. Basically the kvm-vgic interrupt controller registers its
> qemu_irqs with k
Hi Paolo,
thanks for taking the time to explain. I will rewrite accordingly.
Best Regards
Eric
On 04/23/2015 11:58 AM, Paolo Bonzini wrote:
>
>
> On 23/04/2015 11:40, Eric Auger wrote:
Why can't you just use a GHashTable?
>> You mean implementing this hash table in the interrupt controll
On 23/04/2015 11:40, Eric Auger wrote:
>> > Why can't you just use a GHashTable?
> You mean implementing this hash table in the interrupt controller?
No, in KVM. Basically the kvm-vgic interrupt controller registers its
qemu_irqs with kvm-all.c, passing the gsi number for KVM_IRQFD along
the
Hi Paolo,
On 04/23/2015 11:30 AM, Paolo Bonzini wrote:
>
>
> On 23/04/2015 10:49, Eric Auger wrote:
>> This series introduces a new callback function in IRQState, named
>> get_gsi_cb. It is supposed to be populated by the interrupt controller
>> and its role is to convert the interrupt controller
On 23/04/2015 10:49, Eric Auger wrote:
> This series introduces a new callback function in IRQState, named
> get_gsi_cb. It is supposed to be populated by the interrupt controller
> and its role is to convert the interrupt controller pin number into
> the global system interrupt (gsi) number. The
12 matches
Mail list logo
