Hi
On Thu, May 21, 2026 at 11:56 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, May 21, 2026 at 01:49:01AM +0400, Marc-André Lureau wrote:
> > Hi,
> >
> > This series makes HMP compile-time optional via --disable-hmp. The
> > resulting binary speaks only QMP - reducing the attack surface, binary
> > size and enforcing a separation between machine-readable interface and
> > interactive debugging console.
> >
> > QMP offers almost all the functionality HMP could provide, so a separate
> > standalone "HMP-like" console could be implemented on top of it. The
> > rough list of missing commands (+complexity estimation) after this
> > series:
>
> When you say "complexity estimation" is that an estimate for doing
> a well designed QMP implementation ?
>
> My view is that for anything still HMP-only, we should do a quick
> & dirty hack, where we just expose the existing functionality
> directly as QMP without any modelling, but mark it unstable. That
> would make everything be largely easy.
If that's reasonable, we can have more x-unstable HumanReadableText commands.
>
> If we expect proper QMP design, then the job will never get finished.
Yeah, I expect to have a bit better than just plain string though, for
some commands. We can do it progressively.
See for example x-query-usernet & x-query-network added in this
series, they are structured, but a few info fields remain "free-form"
(slirp data, etc).
We could work on exposing the other missing commands in separate series.
>
>
> > Debugging / introspection:
> > - info registers (medium) - plus $reg expression handling
> > - x/xp read memory (medium)
> > - gpa2hpa/gpa2hva/gva2gpa address translation (medium)
> > - info lapic (high) - deep x86 APIC state, lots of registers
> > - info mem (high) - virtual memory mappings, different per arch
> > - info tlb (high) - virt-to-phys mappings, also per arch
> > - info mtree (high) - memory region tree, multiple view modes
> > - info skeys (medium) - s390x storage keys
> > - info cmma (medium) - s390x CMMA values
> > - info qdm (easy) - could probably be folded into QOM introspection
> > - info qtree (medium) - same, maybe QOM introspection is enough
> > - info snapshots (medium)
> > - info usbhost (medium)
> > - info via (medium) -- VIA south bridge state
> >
> > Simple actions / settings:
> > - gdbserver (trivial)
> > - boot_set (easy)
> > - mce (easy) - x86 MCE injection
> > - sum (easy) - memory checksum
> > - sync-profile (easy) - enable/disable/reset
> > - info sync-profile (medium)
> > - one-insn-per-tb (easy) - could be a QOM property on the accelerator
> > - pcie_aer_inject_error (easy)
> > - migration_mode (medium?)
> > - i/o ioport read/write (easy)
> > - hostfwd-add/hostfwd-remove (medium) - slirp port forwarding
> > - log/logfile (medium)
> > - trace-file (medium)
> >
> > Also, to let clients do disassembly on their side, it'd be useful to
> > have something like "query-disassemble-info" that gives the client what
> > architecture and endianness is used etc.
> >
> > In the meantime, being able to build without HMP is valuable and helps
> > identifying the missing pieces. The series does so by steps:
> >
> > - preparatory cleanups and bug fixes
> > - add commands without QMP equivalent and needed for tests
> > - convert most iotests and qtests from HMP to QMP
> > - guard HMP-only code paths
> > - make HMP source files conditional in the build system
> >
>
> With regards,
> Daniel
> --
> |: https://berrange.com ~~ https://hachyderm.io/@berrange :|
> |: https://libvirt.org ~~ https://entangle-photo.org :|
> |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
>
>