riscv: Define __PCI_REROUTE_INTERRUPT

[jrtc27]

Summary

Every other architecture defines this and this is required for
interrupts to work when using QEMU's PCI VirtIO devices (which all
report an interrupt line of 0) for two reasons.

Firstly, interrupt line 0 is wrong; they use one of 0x20-0x23 with the
lines being cycled across devices like normal. Moreover, RISC-V uses
INTRNG, whose IRQs are virtual as indices into its irq_map, so even if
we have the right interrupt line we still need to try and route the
interrupt in order to ultimately call into intr_map_irq and get back a
unique index into the map for the given line, otherwise we will use
whatever happens to be in irq_map[line] (which for QEMU where the line
is initialised to 0 results in using the first allocated interrupt,
namely the RTC on IRQ 11 at time of commit).

Note that pci_assign_interrupt will still do the wrong thing for INTRNG
when using a tunable, as it will bypass INTRNG entirely and use the
tunable's value as the index into irq_map, when it should instead
(indirectly) call intr_map_irq to allocate a new entry for the given
IRQ and treat the tunable as stating the physical line in use, which is
what one would expect. This, however, is a problem shared by all INTRNG
architectures, and not exclusive to RISC-V.

[kib]

So does it work for !QEMU, i.e. real hardware of FPGA ?

[jrtc27]

I don't have meaningful hardware with PCIe to try it on, so I can't say for sure, but every single other architecture in the tree defines this and works correctly (including arm64 which the riscv port is primarily based on) so I struggle to see why it would be a problem to enable it specifically for RISC-V. I suspect that real hardware leaves the registers initialised to 0xFF, i.e. invalid, so having the force_route flag set makes no difference. I can't see how it would possibly work otherwise on real hardware given the use of INTRNG, unless the indices line up purely by chance.

[kib]

So does it make sense to remove __PCI_REROUTE_INTERRUPT ? Perhaps this is a question to John.

[jhb]

If all architectures support it now we probably should make it unconditional.