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" <mst@xxxxxxxxxx> wrote: > > On Mon, Dec 19, 2011 at 09:38:42PM +1030, Rusty Russell wrote: > > > On Mon, 19 Dec 2011 11:13:26 +0200, "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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 :) > > > > > 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? _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
