Avi Kivity wrote:
Suppose you have a command which changes the meaning of a
notification. If a notification arrives before the command
completion, then it happened before the command was executed.
If you want to make that reliable, you cannot have multiple monitors.
Since you can mask notifications, there can be an arbitrarily long time
between notification and the event happening. Socket buffering presents
the same problem. Image:
Monitor 1:
time 0: (qemu) hotadd_cpu 2
time 1: (qemu) hello world <no new line>
time 5: <new line>
time 6: notification: cpu 2 added
time 6: (qemu)
Monitor 2:
time 3: (qemu) hotremove_cpu 2
time 4: (qemu)
time 5: notification: cpu 2 removed
time 6: (qemu)
So to eliminate this, you have to ban multiple monitors. Fine, let's
say we did that, it's *still* racy because at time 3, the guest may hot
remove cpu 2 on it's own since the guests VCPUs get to run in parallel
to the monitor.
And even if you somehow eliminate the issue around masking
notifications, you still have socket buffering that introduces the same
problem.
The best you can do is stick a time stamp on a notification and make
sure the management tool understands that the notification is
reflectively of the state when the event happened, not of the current
state. FWIW, this problem is not at all unique to QEMU and is generally
true of most protocols that support an out-of-band notification mechanism.
--
Regards,
Anthony Liguori