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:
parent
164aa1e941
commit
7de649170f
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user