From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: Using PCI config space to indicate config location Date: Tue, 16 Oct 2012 23:45:41 +1030 Message-ID: <87k3uqpngi.fsf@rustcorp.com.au> 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> <20121012100231.GA32517@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: "Michael S. Tsirkin" Return-path: Received: from ozlabs.org ([203.10.76.45]:34154 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890Ab2JPNQf (ORCPT ); Tue, 16 Oct 2012 09:16:35 -0400 In-Reply-To: <20121012100231.GA32517@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: "Michael S. Tsirkin" writes: > 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. I was assuming the implementation would keep two complete copies of the config space: writes go to the scratch version, which gets copied to the master version upon latch write. But I do wonder if we should just skip this for now, since we don't have any immediate need. Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO70m-0004Bc-VN for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:16:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TO70g-0001DZ-AJ for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:16:44 -0400 Received: from ozlabs.org ([203.10.76.45]:48754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TO70f-0001Cl-VG for qemu-devel@nongnu.org; Tue, 16 Oct 2012 09:16:38 -0400 From: Rusty Russell In-Reply-To: <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> <20121012100231.GA32517@redhat.com> Date: Tue, 16 Oct 2012 23:45:41 +1030 Message-ID: <87k3uqpngi.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org "Michael S. Tsirkin" writes: > 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. I was assuming the implementation would keep two complete copies of the config space: writes go to the scratch version, which gets copied to the master version upon latch write. But I do wonder if we should just skip this for now, since we don't have any immediate need. Cheers, Rusty.