On Thu, Jan 08, 2026 at 12:35:07PM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Thu, Jan 08, 2026 at 08:57:59AM +0100, Markus Armbruster wrote: > >> Bin Guo <[email protected]> writes: > >> > >> > Daniel P. Berrangé wrote on Mon, 5 Jan 2026 10:37:16 +0000: > >> > > >> >> Missing commit message explaining why we should do this ? > >> > > >> > The reason for submitting this patch is that the newly supported > >> > 'info accelerators' command can provide a more comprehensive view > >> > of the accelerator's status. > >> > >> Should we deprecate "info kvm"? > > > > Conceptually it is certainly redundant, and for HMP we offer no long > > term stability promise. Is the benefiting of deprecating and then > > removing it, worth the inconvenience we'll cause ? > > > > Perhaps the more important Q first is whether we should deprecate > > query-kvm in QMP ? > > Yes. > > "info kvm" is a thin wrapper around query-kvm. We should either keep > both or neither. > > What should management applications use, query-kvm or > query-accelerators?
Functionally it doesn't matter which they use if they care about KVM state. Conceptually we want them to prefer the latter since it means their code is more portable to other accelerators QEMU has. > > If our answer is query-accelerators, we should guide them by deprecating > query-kvm now. This doesn't mean we must delete it as soon as the > deprecation grace period ends. > > If our answer is "we don't care", we can keep query-kvm. > > If our answer is query-kvm, adding query-accelerators was a mistake. > But I don't think it is. Yeah, feels like we want the query-kvm deprecation. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
