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
