On 10/27/25 7:34 PM, Andrea Bolognani wrote:
On Mon, Oct 27, 2025 at 06:23:55PM -0300, Daniel Henrique Barboza wrote:
On 10/27/25 4:49 PM, Andrea Bolognani wrote:
I'm also wondering how the riscv-aia KVM feature you're introducing will interact with the existing aia feature. The latter is documented somewhat extensively in
https://gitlab.com/qemu-project/qemu/-/blob/master/docs/specs/riscv-aia.rst
but AFAICT there barely is any documentation at all for the former at the QEMU level. Maybe Daniel (CC'd), who introduced the other feature into libvirt, knows more.
Having a 'riscv-aia' KVM accel prop and an 'aia' board property is confusing indeed ...
What we added in libvirt is the 'virt' board AIA support (aplic and aplic-imsic). It interacts with the current accelerator capabilities (kvm, tcg) like the QEMU doc above describes.
The 'riscv-aia' accelerator property attempts to configure the capabilities of the in-kernel KVM AIA chip, if present.
[...]
Note that these are properties implemented by the KVM module, not QEMU, e.g. they depend on host KVM support.
[...]
As far as libvirt goes I wouldn't add 'auto' support. Not only it is already the QEMU default value but it also means "give me either hwaccel or emul". Might as well just leave the option alone then.
I am also under the impression that modeling that value explicitly is probably not useful.
Hope this helps. I'll send a patch adding the riscv-aia info to the QEMU docs.
Thanks. Having better documentation on the QEMU side will not only guide our decisions on the libvirt side, but obviously also benefit people who run QEMU directly.
All true. Btw just posted it in the QEMU ML.
If you have any opinion on what the libvirt interface should look like, please do share. You clearly understand the problem space much better than I do :)
As far as this series goes, aside from my comment w.r.t the 'auto' setting I think these patches are on the right direction. 'riscv-aia' should be handled like any other accel property that libvirt already supports (e.g. dirty-ring-size). With proper documentation stating that riscv-aia is a RISC-V only property, of course. As libvirt + risc-v in general I'm happy with how libvirt is faring. libvirt is way ahead of the curve w.r.t features (device plug/unplug, migration management, device assignment, etc) in comparison with what the current risc-v ecosystem. The caveat is extension management, a.k.a how do we disable extensions in libvirt. QEMU supports 142 extensions at this moment. The right thing to do would be to add each single one of them in libvirt (we can't just create a XML element that receives any user input as "extensions to be disabled" and roll with it). But the more I think about it the more I believe that we shouldn't add any generic extension disable support in libvirt ... disabling extensions is a debug feature more than anything, an advanced feature that most users will misuse and then nag about their stuff not working. If there's real RISC-V HW that needs extensions to be disabled to work properly, then so be it - add support to disable the required extensions only. Do it on demand. Thanks, Daniel