From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMc34-0001pQ-QM for qemu-devel@nongnu.org; Fri, 12 Oct 2012 06:01:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMc2u-0006hI-6s for qemu-devel@nongnu.org; Fri, 12 Oct 2012 06:00:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMc2t-0006gP-Sv for qemu-devel@nongnu.org; Fri, 12 Oct 2012 06:00:44 -0400 Date: Fri, 12 Oct 2012 12:02:31 +0200 From: "Michael S. Tsirkin" Message-ID: <20121012100231.GA32517@redhat.com> References: <87zk4c2tqq.fsf@rustcorp.com.au> <874nmajcmj.fsf@codemonkey.ws> <87y5jhpuu2.fsf@rustcorp.com.au> <20121010083033.GA4799@redhat.com> <87bog9957l.fsf@rustcorp.com.au> <20121011102333.GA5552@redhat.com> <87391k7icv.fsf@rustcorp.com.au> <20121012093330.GA32014@redhat.com> <871uh4587d.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871uh4587d.fsf@rustcorp.com.au> Subject: Re: [Qemu-devel] Using PCI config space to indicate config location List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" writes: > > On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote: > >> >> For writes, the standard seems to be a commit latch. We could abuse the > >> >> generation count for this: the driver writes to it to commit config > >> >> changes. > >> > > >> > I think this will work. There are a couple of things that bother me: > >> > > >> > This assumes read accesses have no side effects, and these are sometimes handy. > >> > Also the semantics for write aren't very clear to me. > >> > I guess device must buffer data until generation count write? > >> > This assumes the device has a buffer to store writes, > >> > and it must track each byte written. I kind of dislike this > >> > tracking of accessed bytes. Also, device would need to resolve conflicts > >> > if any in some device specific way. > >> > >> It should be trivial to implement: you keep a scratch copy of the config > >> space, and copy it to the master copy when they hit the latch. > >> > >> Implementation of this will show whether I've missed anything here, I > >> think. > > > > What I refer to: what happens if driver does: > > - write offset 1 > > - write offset 3 > > - hit commit latch > > - nothing > - nothing > - effect of offset 1 and offset 3 writes OK so this means that you also need to track which bytes where written in order to know to skip byte 2. This is what I referred to. If instead we ask driver to specify offset/length explicitly device only needs to remember that. Not a big deal anyway, just pointing this out. > Now, since there's nothing published by the *driver* at the moment > which can't be trivially atomically written, this scheme is overkill > (sure, it means you could do a byte-at-a-time write to some 4-byte > field, but why?). > > But perhaps it's overkill: no other bus has this feature, so we'd need a > feature bit for them anyway in future if we create a device which needs > such atomicity. > > Cheers, > Rusty.