Hi On Thu, May 21, 2026 at 11:56 AM Daniel P. Berrangé <[email protected]> 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 :| > >
