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

[Michael S. Tsirkin]

On Wed, May 30, 2012 at 10:23:16PM +0200, Jan Kiszka wrote:
> On 2012-05-30 21:30, Michael S. Tsirkin wrote:
> > On Wed, May 30, 2012 at 09:06:25PM +0200, Jan Kiszka wrote:
> >> On 2012-05-30 20:51, Michael S. Tsirkin wrote:
> >>> On Wed, May 30, 2012 at 09:29:13PM +0300, Michael S. Tsirkin wrote:
> >>>> On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote:
> >>>>> On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote:
> >>>>>> On 2012-05-30 19:51, Jan Kiszka wrote:
> >>>>>>>> Well, I'll stop ranting here.  The patch that I sent is not intrusive
> >>>>>>>> and simply gives you a simple way to implement 
> >>>>>>>> pci_device_get_host_irq,
> >>>>>>>> also optimizing emulated devices somewhat.  So if you think you need
> >>>>>>>> pci_device_get_host_irq I think this is a reasonable way to support
> >>>>>>>> that.  But if you changed your mind, I don't mind.
> >>>>>>>
> >>>>>>> Sorry, your patch doesn't help me in any way.
> >>>>>>
> >>>>>> [to finish the sentence]
> >>>>>>
> >>>>>> ...as it doesn't handle the final routing step in the host bridge.
> >>>>>
> >>>>> I think you mean the logic in piix3_set_irq_level?
> >>>>>
> >>>>> True. I suggest we make piix3_set_irq_level use the map_irq
> >>>>> infrastructure somehow:
> >>>>
> >>>> BTW, can't we simply override map_irq and make it read from
> >>>> piix3->dev.config[PIIX_PIRQC + pirq]?
> >>>
> >>> Basically move
> >>>     pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
> >>> to pci_slot_get_pirq.
> >>
> >> map_irq might be reused, but not that easily as the return value is used
> >> as irq_count index.
> >>
> >> Jan
> > 
> > So we'll just have PIIX_NUM_PIC_IRQS entries there and use
> > irq_count instead of the pic_levels bitmap.
> 
> Just that this affects generic PCI code, not only PIIX-specific things.

Yes but it's not a problem - pci_bus_irqs sets the map function and nirqs.

> And that we need to save/restore some irq_count field according to the
> old semantics.

Well, it's a bug: this is redundant info we should not have exposed it.

Anyway, let's make the rest work properly and cleanly first, add a FIXME
for now, then we'll find a hack making it work for migration.

> As I said: not that easy. :)
> 
> Jan
>