Re: [Qemu-devel] [PATCH 1/2] pci: Add pci_device_get_host_irq

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, May 21, 2012 at 05:35:34PM -0300, Jan Kiszka wrote:
> On 2012-05-21 16:05, Michael S. Tsirkin wrote:
> > On Mon, May 21, 2012 at 10:13:47AM -0300, Jan Kiszka wrote:
> >> @@ -386,6 +387,14 @@ static void piix3_set_irq(void *opaque, int pirq, int level)
> >>      piix3_set_irq_level(piix3, pirq, level);
> >>  }
> >>  
> >> +static int piix3_map_host_irq(void *opaque, int pci_intx)
> >> +{
> >> +    PIIX3State *piix3 = opaque;
> >> +    int host_irq = piix3->dev.config[PIIX_PIRQC + pci_intx];
> >> +
> >> +    return host_irq < PIIX_NUM_PIC_IRQS ? host_irq : -1;
> >> +}
> >> +
> >>  /* irq routing is changed. so rebuild bitmap */
> >>  static void piix3_update_irq_levels(PIIX3State *piix3)
> >>  {
> > 
> > 
> > So, instead of special API just for assignment,
> > I would like to see map_irq in piix being reworked
> > to take dev config into account.
> > I think piix is almost unique in this but need to check,
> 
> Maybe it is the only host bridge with routing that we have in QEMU right
> now, but it is surely not unique (e.g. all later Intel chipsets support
> this).

Yes. APIs for this should be in place. Just saying
instead of failing we can easily just make it work
if there are no remappings.

> > if not fix other host buses that are programmable.
> > PCI bridges are all fixed routing.
> > 
> > Then we can drop set_irq callback.
> 
> set_irq may do more than IRQ routing. It may also flip polarity (see
> bonito.c).

In that case host_map_irq is not a good API?
Need to investigate.

> I guess we need to analyze the requirements of all in-tree
> host bridges first.

Yes.

> > 
> > Finally all devices can cache the irq#,
> > and piix would scan devices behind it
> > and update the irq.
> > 
> > Assignment then just needs a notifier, since
> > it owns the device just a pointer in device is
> > enough.
> 
> I cannot completely follow your ideas here yet. Do you want to pass the
> mapping information along the notifier, or why "just ... a notifier"?


Each device would resolve IRQs that it uses.


> > 
> > Could you look at doing this please?
> > If no I can give it a stub.
> > 
> 
> Unless we can converge over a final API quickly, I would suggest to base
> these refactorings on top of what I propose here. We will have to touch
> all host bridges more invasively for this anyway. If you can explain to
> me how simple the refactoring can be (but I'm a bit skeptical ;) ), I
> could do this, otherwise I would prefer to focus on the device
> assignment topic which provide some more nuts.
> 
> Jan

Yes it's simple. I'll post in a couple of days (lots of
meetings tomorrow). I think you'll
see it's easier and cleaner.

> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux