From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: Using PCI config space to indicate config location Date: Fri, 12 Oct 2012 11:33:30 +0200 Message-ID: <20121012093330.GA32014@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87391k7icv.fsf@rustcorp.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Rusty Russell Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org 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 ? -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMbas-0000If-LF for qemu-devel@nongnu.org; Fri, 12 Oct 2012 05:31:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMbao-0004uT-EM for qemu-devel@nongnu.org; Fri, 12 Oct 2012 05:31:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMbao-0004u9-6E for qemu-devel@nongnu.org; Fri, 12 Oct 2012 05:31:42 -0400 Date: Fri, 12 Oct 2012 11:33:30 +0200 From: "Michael S. Tsirkin" Message-ID: <20121012093330.GA32014@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87391k7icv.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: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 ? -- MST