vmm: fix riscv64 legacy serial MMIO setup#591
Conversation
|
PTAL |
|
It would be nice to put the PR description to the commit message. |
done. PLZ |
mz-pdm
left a comment
There was a problem hiding this comment.
Thank you for adding the commit message. It would be even better if the markup, namely the backslashes and the double quote at the end, were removed, but other than that the change looks good to me.
Fix `cargo check` failures for the `riscv64gc-unknown-linux-gnu` target caused by an unsynchronized legacy serial initialization chain. Changes include: - Correct `attach_legacy_devices()` in `builder.rs` which incorrectly referenced a non-existent `serial_device`. - Remove invalid `serial.set_intc(intc)` call in KVM MMIO serial registration. Unlike Aarch64, the RISCv64 legacy serial does not support active interrupt injection via an internal interrupt controller. Instead, interrupt triggering relies on the registered IRQFD. This aligns the RISCv64 boot path with the architecture's actual interrupt handling capabilities. Signed-off-by: Zewei Yang <yangzewei@loongson.cn>
got it. |
slp
left a comment
There was a problem hiding this comment.
NAK. RISCV does have its own IrqChip abstraction, KvmAia. The serial device implementation should be updated to install it via set_intc and make use of it for triggering interrupts.
Background
In the RISCv64 boot path, the legacy serial initialization chain is not synchronized, causing
cargo check -p vmm --target riscv64gc-unknown-linux-gnuto fail to compile.The
attach_legacy_devices()method inbuilder.rscalls a non-existentserial_device.The KVM MMIO serial registration logic for RISCv64 calls a non-existent
serial.set_intc(intc). The current RISCv64 legacy serial does not provide this interface; its interrupt triggering path depends on the registered IRQFD, rather than actively injecting interrupts through the interrupt controller held by the serial device as in Aarch64.