Re: [PATCH 0/5] Fix recent PIC -> CPU interrupt wiring regressions

[Peter Maydell]

On Sat, 4 Mar 2023 at 13:30, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Sat, 4 Mar 2023, Bernhard Beschow wrote:
> > A recent series [1] attempted to remove some PIC -> CPU interrupt 
> > indirections.
> > This inadvertantly caused NULL qemu_irqs to be passed to the i8259 because 
> > the
> > qemu_irqs aren't initialized at that time yet. This series provides a fix by
> > initializing the qemu_irq of the respective south bridges before they
> > are passed to i2859_init().
> >
> > Furthermore -- as an optional extension -- this series also fixes some 
> > usability
> > issues in the API for creating multifunction PCI devices.
> >
> > The series is structured as follows: The first three commits fix the
> > regressions, the last two fix the public API for creating multifunction PCI
> > devices.
> >
> > [1] 
> > 20230302224058.43315-1-philmd@linaro.org/">https://lore.kernel.org/qemu-devel/20230302224058.43315-1-philmd@linaro.org/
> >
> > Bernhard Beschow (5):
> >  hw/isa/vt82c686: Fix wiring of PIC -> CPU interrupt
> >  hw/alpha/dp264: Fix wiring of PIC -> CPU interrupt
> >  hw/ppc/prep: Fix wiring of PIC -> CPU interrupt
> >  hw/pci/pci: Remove multifunction parameter from
> >    pci_create_simple_multifunction()
> >  hw/pci/pci: Remove multifunction parameter from
> >    pci_new_multifunction()
>
> I'd postopne the last two API change patches to the next release. Ideally
> the device itself should know if it's multifunction or not and the board
> instantiating it should not do anything different than instantiating a
> single function device so we's only need pci_new or pci_create_simple
> without multifunction parameter or variant. So my question is why do we
> need these at all and could this be simplified more? But there's not
> enough time to answer that now so I'd ask to leave these alone for now and
> come back to this in next devel cycle.
>
> The other 3 patches fix a breakaga in current master so can be considered
> but I'd need to know a decision if this will be taken or a revert as I
> need to rebase my pending patches accordingly. A maintainer please speak
> up here.

If we're happy that patches 1-3 fix the regressions and look OK
code-wise then applying them is probably the simplest thing.

thanks
-- PMM