Implement IMSIC and APLIC according to AIA spec

[X547]

RISC-V Advanced Interrupt Architecture (AIA) specification: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf.

Reference code (QEmu):

• https://github.com/qemu/qemu/blob/master/include/hw/intc/riscv_imsic.h
• https://github.com/qemu/qemu/blob/master/hw/intc/riscv_imsic.c
• https://github.com/qemu/qemu/blob/master/include/hw/intc/riscv_aplic.h
• https://github.com/qemu/qemu/blob/master/hw/intc/riscv_aplic.c

[LekKit]

I've done research on what and how to implement, but I'm not sure I can guarantee a conforming and tested implementation until there are proper upstream Linux drivers. It seems there are some patches on the mailing list, though, so worth looking at.
Until it's upstream and there is practical use to it, the priority will be lowered - hope that makes sense.

[LekKit]

According to my VF2, it uses MSI over the standard PLIC. You have any idea how that should be actually routed?

According to PCI 2.2, the MSI vector address is architecture-specific. I am wondering if that's supported in Haiku.

[X547]

According to my VF2, it uses MSI over the standard PLIC. You have any idea how that should be actually routed?

Maybe MSI writing to priority threshold of PLIC context while interrupt pin is hardwired to one? I can' find related code in Linux kernel.

According to PCI 2.2, the MSI vector address is architecture-specific.

PCIe allows to write some configured 16 bit value to any configured physical address. As long there are some MMIO register that can trigger interrupt on write, it can be used for MSI.

I am wondering if that's supported in Haiku.

Haiku use Designware PCI host controller built-in MSI interrupt controller for HiFive Unmatched. In my rvvm2 branch I made generic MSI controller interface.

[LekKit]

Haiku use Designware PCI host controller built-in MSI interrupt controller for HiFive Unmatched. In my rvvm2 branch I made generic MSI controller interface.

Okay makes sense. Seemingly there are 3 (4) ways:

• Designware PCI with built-in MSI
• PLDA PCI (found on VF2) with built-in MSI (Barely getting merged in 6.3 or 6.4)
• Standardized IMSIC (Not yet merged in Linux, patches floating on mailing list and apparently they are still waiting for something to confirm the spec is stable)
• Generic PCI + pin INTX over PLIC

Maybe MSI writing to priority threshold of PLIC context while interrupt pin is hardwired to one? I can' find related code in Linux kernel.

Lol that's a cool idea, but I doubt anyone actually did it.

[X547]

Any chance to implement Designware PCI and/or PLDA PCI with MSI support in RVVM?

[LekKit]

Any chance to implement Designware PCI and/or PLDA PCI with MSI support in RVVM?

If it can be done without breaking pci-bus abstractions much, and implemented as different variations of the same pci-bus device (Generic+IMSIC/PLDA/whatever), then yeah. I am not sure if this will happen soon, though.

My current list of whatever I'm busy with, FYI:

• Doing something productive with my life
• Consuming a lot of literature either to help with RVVM development or in general
• blk-dedup format for efficiently storing multiple VM images (basically N VMs with same OS installed will use 1/N the space). It is kinda working good but there are stability/perf issues I need to address.
• Figuring out the best VM suspend API/approach
• Some major interpreter changes are among the way. TLDR: Current table-based dispatch is unusable for Bitmanip/Vector/etc extensions, it may be expanded (to whopping 256kb per core! this is too much and annihilates L1d) or entire interpreter may need rewriting in switches (Apparently they are faster than I thought, yet it is unclear if interpreter will be faster or slower and the FPU/MISA disabling is tricky).
• Hacking on RVJIT SSE2/AVX/BMI codegen
• Hacking tap_user, nothing worth upstreaming yet

[X547]

I have experimental APLIC/IMSIC support in my https://github.com/X547/haiku/tree/device_manager2 branch.

[LekKit]

Basically I want to look a bit more if fixing the weird i2c-hid hanging we spoke in #126 is possible, then release stable v0.6 for people to poke at and have something reliable to roll back if anything goes wrong. Then a lot of rewriting will happen:

• Rewriting the interpreter; This should easily allow to interpret B extension then
• Rewriting IRQ API (perhaps) to support APLIC/IMSIC properly
• APLIC/IMSIC implementation, but it shouldn't break guests which only support PLIC
• Merging experimental blk-dedup block layer which is already implemented locally but corrupts images sometimes and better performance is desired so WIP
• VT API & chardev
• Possibly virtio-balloon to reduce RAM usage; See vma_clean() function in src/vma_ops.c - we can clean up pages if gust reports them as unused
• Rewriting any APIs that are deemed limited or unsatisfactory during the stable v0.6 lifetime

If you wish to see anything else in v0.6, please tell me. But I just want to stop polishing it at this point.

[X547]

APLIC/IMSIC implementation, but it shouldn't break guests which only support PLIC

PLIC and APLIC are mutually-exclusive. It is not possible to run PLIC only system on hardware with APLIC. Note that interrupt controller need some handling by machine mode code such as OpenSBI, but it don't know about which interrupt controller will be used by supervisor mode code.

[LekKit]

PLIC and APLIC are mutually-exclusive. It is not possible to run PLIC only system on hardware with APLIC.

I see some notes on compatibility mode in APLIC documentation where it mentions PLIC regmap supplied alongside APLIC.

[X547]

Only one of them can be configured at boot and it should be done from machine mode code.

[LekKit]

APLIC & IMSIC drivers got merged into Linux 6.10, so that's a good point to start soon.