[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with irq mapping in qemu v5.2
From: |
Guenter Roeck |
Subject: |
Problems with irq mapping in qemu v5.2 |
Date: |
Tue, 22 Dec 2020 08:16:41 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
Hi,
commit 459ca8bfa41 ("pci: Assert irqnum is between 0 and bus->nirqs in
pci_bus_change_irq_level") added sanity checks to the interrupt number passed
to pci_bus_change_irq_level(). That makes sense, given that bus->irq_count
is indexed and sized by the number of interrupts.
However, as it turns out, the interrupt number passed to this function
is the _mapped_ interrupt number. The result in assertion failures for various
emulations.
Examples (I don't know if there are others):
- ppc4xx_pci_map_irq() maps the interrupt number to "slot - 1". Obviously
that isn't a good thing to do for slot 0, and indeed results in an
assertion as soon as slot 0 is initialized (presumably that is the root
bridge). Changing the mapping to "slot" doesn't help because valid slots
are 0..4, and only four interrupts are allocated.
- pci_bonito_map_irq() changes the mapping all over the place. Whatever
it does, it returns numbers starting with 32 for slots 5..12. With
a total number of 32 interrupts, this again results in an assertion
failure.
ppc4xx_pci_map_irq() is definitely buggy. I just don't know what the
correct mapping should be. slot & 3, maybe ?
I don't really have a good solution for pci_bonito_map_irq(). It may not
matter much - I have not been able to boot fuloong_2e since qemu v4.0,
and afaics that is the only platform using it. Maybe it is just completely
broken ?
Thanks,
Guenter