On Wed, Jul 19, 2017 at 10:17:36AM -0500, Eric Blake wrote: > On 07/19/2017 10:07 AM, Daniel P. Berrange wrote: > >> It doesn't. Perhaps we should add that as a future libvirt-qemu.so API > >> addition, although it's probably easier to just use QMP than HMP when > >> using 'virsh qemu-monitor-command' if HMP doesn't do what you want. > > > > Or special case the "cpu 1" command - ie notice that it is being > > requested and don't execute 'human-montor-command'. Instead just > > record the CPU index, and use that for future "human-monitor-command" > > invokations, so we get full compat with the (dubious) stateful HMP > > semantics that traditionally existed. > > Is 'cpu' (and the followup commands affected by it) the only stateful > HMP command pairing? Is there a way to specify multiple HMP commands in > a single human-monitor-command QMP call? > > Indeed, tweaking qemu's human-monitor-command call to track the state > might be cleaner than having libvirt have to tweak API to work around > this wart of HMP. The CPU index was the only state kept by the human monitor, and I think it's by design that it stopped being considered "monitor state" to be tracked, and became just an argument to human-monitor-command. It's true that it broke compatibility of "virsh qemu-monitor-command <domain> --hmp 'cpu <n>'", when we moved to QMP, but this happened years ago, and it looks like nobody was relying on it. I don't see the point of trying to emulate the previous stateful interface. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
