Re: Is the ppc440 "bamboo" board in QEMU still of any use?

[Thomas Huth]

On 14/10/2021 13.44, Mark Cave-Ayland wrote:
> On 14/10/2021 11:47, Christophe Leroy wrote:
>
> > Le 14/10/2021 à 12:34, Christophe Leroy a écrit :
> > > Le 14/10/2021 à 11:31, Thomas Huth a écrit :
> > > >   Hi,
> > > >
> > > > I tried to build a current Linux kernel for the "bamboo" board and use 
> > > > it in QEMU, but QEMU then quickly aborts with:
> > > >
> > > >   pci.c:262: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
> > > >
> > > > (or with a "DCR write error" if I try to use the cuImage instead).
> > > >
> > > > I googled a little bit and found this discussion:
> > > >
> > > > https://qemu-devel.nongnu.narkive.com/vYHona3u/emulating-powerpc-440ep-with-qemu-system-ppcemb#post2 
> > > >
> > > >
> > > > Seems like this board was used for KVM on the PPC440 only, and has never 
> > > > been enabled with the TCG emulation?
> > > >
> > > > Well, KVM support on the 440 has been removed years ago already:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2677b8dd8de0dc1496ede4da09b9dfd59f15cea 
> > > >
> > > >
> > > > So is this "bamboo" board dead code in QEMU now? Or does anybody still 
> > > > have a kernel binary which could be used for testing it? Note: This 
> > > > board does not support "-bios", so u-boot or other firmwares are 
> > > > certainly also not an option here...
> > > > Should we mark "bamboo" as deprecated nowadays?
> > >
> > > I have the following change in QEMU to be able to run the bamboo, found 
> > > it some time ago via google (can't remember where):
> > >
> > > diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> > > index 8147ba6f94..600e89e791 100644
> > > --- a/hw/ppc/ppc4xx_pci.c
> > > +++ b/hw/ppc/ppc4xx_pci.c
> > > @@ -246,7 +246,7 @@ static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int 
> > > irq_num)
> > >
> > >       trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot);
> > >
> > > -    return slot - 1;
> > > +    return slot ? slot - 1 : slot;
> > >   }
> > >
> > >   static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> > > ---
> > >
> > > It's probably no the final change, but at least it allows booting bamboo 
> > > on qemu again.
> >
> > Found the source : 
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg769121.html
>
> Ah yes, that thread rings a bell. I think the important part was in my 
> initial reply at 
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg769115.html: in other 
> words ppc4xx_pci_map_irq() function expects the IRQ number to range from 1 
> to 4.
>
> When I looked at this the issue was caused by the guest writing to PCI 
> configuration space to disable PCI interrupts: this ends up calling 
> pci_update_irq_disabled() as below:
>
> /* Called after interrupt disabled field update in config space,
>   * assert/deassert interrupts if necessary.
>   * Gets original interrupt disable bit value (before update). */
> static void pci_update_irq_disabled(PCIDevice *d, int was_irq_disabled)
> {
>      int i, disabled = pci_irq_disabled(d);
>      if (disabled == was_irq_disabled)
>          return;
>      for (i = 0; i < PCI_NUM_PINS; ++i) {
>          int state = pci_irq_state(d, i);
>          pci_change_irq_level(d, i, disabled ? -state : state);
>      }
> }
>
> Since the IRQ is disabled pci_change_irq_level() ends up being called with 
> -1 which triggers the assert().

I think you likely mixed up the paramters here. The -1 is the "change" 
parameter, but the critical value that is tested in the assert() statement 
later is the irq_num variable which comes from the map_irq() function.

Now looking at ppc4xx_pci_map_irq(), I think the code is basically correct 
for the PCI slots 1 to 4. You can verify that with the image from


http://landley.net/aboriginal/downloads/binaries/system-image-powerpc-440fp.tar.gz

and by starting QEMU e.g. with:

qemu-system-ppc64  -kernel linux -initrd rootfs.cpio.gz \
  -M bamboo -device e1000  -device e1000 -device e1000 \
  -netdev user,id=u1 -device rtl8139,netdev=u1

You can see the 8139 card with "lspci" in the last slot, and a "ping 
10.0.2.2" only works if the map_irq function returns "slot - 1" in this case 
(otherwise it even crashes after a while).

Now back to the original problem: This seems to occur indeed since recent 
self-compiled Linux kernels also try to mess with the pci host bridge device 
in slot 0. So the question is only, which interrupt number should the 
map_irq() function return in case it has been called with the PCI host 
bridge device in slot 0?

Both hacks with "return slot ? slot - 1 : 0;" and "return (slot - 1) & 3" 
seem to work, as far as I can tell, and I think the IRQ for the host bridge 
is then ignored anyway, so maybe we should simply add one of the two and 
call it a day?

 Thomas