Re: Modern HMP

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
> One question I have is what exactly gets (eventually) removed from QEMU
> and what benefits we expect from it. Is it the entire "manual"
> interaction that's undesirable? Or just that to maintain HMP there is a
> certain amount of duplication? Or even the less-than-perfect
> readline/completion aspects?

Over time we've been gradually separating our human targetted code from
our machine targetted code, whether that's command line argument parsing,
or monitor parsing. Maintaining two ways todo the same thing is always
going to be a maint burden, and in QEMU it has been especially burdensome
as they were parallel impls in many cases, rather than one being exclusively
built on top of the other.

Even today we still get contributors sending patches which only impl
HMP code and not QMP code. Separating HMP fully from QMP so that it
was mandatory to create QMP first gets contributors going down the
right path, and should reduce the burden on maint.

At some point we are likely to introduce a new non-backwards compatible
QEMU binary. Perhaps when Philippe completes his "all targets/machines
in one binary" work. That would be an opportunity to carve HMP off
into a separate out of process facade talking over QMP.

That's only possible though if we get existing HMP into being a layer
over QMP with no backdoor parallel impls. So anything we can do today
to better separate QMP/HMP will give us more flexibility when the time
arrives to create a new QEMU binary without backwards compat cruft.

NB, introducing a new binary does not imply that the old binaries
go away. They would probably stick around for legacy compat for a
good while. For anything using libvirt though, we would be able to
switch to the new binaries pretty fast without, as libvirt can
translate app XML config to either the new or old QEMU dynamically.

> Does the new program becomes basically an external project unrelated to
> QEMU, that simply talks to QMP like libvirt does?

It could be a separate project under QEMU on github, or it could just be
binary in qemu.git. What matters is that it is out of the main QEMU process
eventually.

> I wonder how close to tools like qmp-shell, qmp-tui, etc that would
> become and whether we might actually be looking at a substitute of
> qemu.qmp.

qmp-shell is rather too crude in terms of its data input/output - have
to switch to JSON way too much, and there's no mechanism for formatting
complex QMP replies into pretty human friendly data.

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 :|