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 >
