On Tue, Oct 28, 2025 at 08:11:02AM -0300, Daniel Henrique Barboza wrote:
On 10/27/25 7:34 PM, Andrea Bolognani wrote:
On Mon, Oct 27, 2025 at 06:23:55PM -0300, Daniel Henrique Barboza wrote:
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.
https://mail.gnu.org/archive/html/qemu-devel/2025-10/msg07285.html
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.
The QEMU documentation is making my head spin - so many different acronyms and the number of possible combinations is just staggering. If I understand things correctly, the riscv-aia accel property is only really relevant in combination with the aia=aplic-imsic machine type property. So we should probably validate that it's not used without it. Other than that, and the comments that I had made previously, I agree that overall the patch looks reasonable.
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.
That's a different topic. For another day ;) -- Andrea Bolognani / Red Hat / Virtualization