LekKit

There is another bug where Linux guest will sometimes hang if `input_available` is called very early in the boot process (For example spamming input on a booting guest). It seems...

> Maybe Linux performs some i2c read/write operations before properly initializing interrupt handler? Is it possible to add logging of `i2c_hid_stop`, `i2c_hid_reset` calls? I have logged raise/lower events of IRQ...

> I think I need to reproduce it myself. What Linux image/version is used? Full setup (firmware/kernel/image). Run as `rvvm fw_jump.bin -k Image -i rootfs.ext2`, also for the hang to...

> Interrupt condition should be cleared inside interrupt handler to avoid infinite interrupt loop, but I2C IO also use interrupts, so I can't find any other reliable solution except disabling...

> See: https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt Passing `interrupts = ;` or `interrupts = ;` (I.e. explaining to guest that this IRQ is level-triggered) doesn't fix the issue. Using `plic_send_irq()` instead of `plic_raise_irq()`, plus...

> Have you changed `#interrupt-cells` to 2? Yes

I think we need to elaborate whether level-triggered interrupts are actually needed. Perhaps Linux driver actually expects edge-triggered interrupts.

> See: https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/sifive%2Cplic-1.0.0.txt ``` While the PLIC supports both edge-triggered and level-triggered interrupts, interrupt handlers are oblivious to this distinction and therefore it is not specified in the PLIC...

> Also setting PLIC `compatible` field to `thead,c900-plic` and using 2 cells may work. In reality THead PLIC is subtly non spec conformant, and has a quirk `PLIC_QUIRK_EDGE_INTERRUPT` in kernel...

> > But this helps with debugging for now; I'll see what actually changes in kernel with this and perhaps either fix it or conclude it's a kernel bug with...