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