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
