riscv: Define __PCI_REROUTE_INTERRUPT

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.

Reviewed by:	kib
Approved by:	kib
Differential Revision:	https://reviews.freebsd.org/D26564
This commit is contained in:
Jessica Clarke 2020-09-30 02:21:38 +00:00
parent 164aa1e941
commit 7de649170f

View File

@ -42,6 +42,8 @@
#define STACKALIGNBYTES (16 - 1)
#define STACKALIGN(p) ((uint64_t)(p) & ~STACKALIGNBYTES)
#define __PCI_REROUTE_INTERRUPT
#ifndef MACHINE
#define MACHINE "riscv"
#endif