[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Date: Thu, 09 Apr 2009 11:09:23 -0500
User-agent: Thunderbird (X11/20090320)

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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]