On Wed, Dec 21, 2011 at 11:03:25AM +1030, Rusty Russell wrote:

On Tue, 20 Dec 2011 13:37:18 +0200, "Michael S. Tsirkin" [off-list ref] wrote:

quoted

On Mon, Dec 19, 2011 at 09:38:42PM +1030, Rusty Russell wrote:

quoted

On Mon, 19 Dec 2011 11:13:26 +0200, "Michael S. Tsirkin" [off-list ref] wrote:

Actually, the host doesn't need anything, since it can always lock out
the guest while it updates the area.
It's the guest which can't do atomic updates.

There are 2 cases
- updates by guest accesses by host
- accesses by guest updates by host

Both are problematic because the guest accesses are split.
Consider the example I gave at the beginning was with capacity read
by guest. Host can not solve it without guest changes, right?

Indeed, my brain fart.  Let's pretend I didn't say that, and you didn't
have to explain it to me in baby words :)

quoted

quoted

quoted

The counter can be in guest memory, right? So we don't pay extra
exits.

Could be, but I'm not delighted about the design.

OK, so this is an argument for always using a control vq, right?

Yes.  The idea that we can alter fields in the device-specific config
area is flawed.  There may be cases where it doesn't matter, but as an
idea it was holed to begin with.

We can reduce probability by doing a double read to check, but there are
still cases where it will fail.

Okay - want me to propose an interface for that?