From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54200 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8LJC-00028D-Qb for qemu-devel@nongnu.org; Tue, 19 Oct 2010 19:09:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8LJB-0003ht-Hk for qemu-devel@nongnu.org; Tue, 19 Oct 2010 19:09:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8LJB-0003hi-9n for qemu-devel@nongnu.org; Tue, 19 Oct 2010 19:09:29 -0400 Date: Wed, 20 Oct 2010 01:02:13 +0200 From: "Michael S. Tsirkin" Message-ID: <20101019230212.GA2380@redhat.com> References: <20101019115131.GA6752@redhat.com> <20101019151947.GA30021@valinux.co.jp> <20101019170655.GA21866@redhat.com> <20101019223637.GC30021@valinux.co.jp> <20101019224048.GA28390@redhat.com> <20101019225556.GE30021@valinux.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101019225556.GE30021@valinux.co.jp> Subject: [Qemu-devel] Re: [PATCH v5 00/14] pcie port switch emulators List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: skandasa@cisco.com, etmartin@cisco.com, qemu-devel@nongnu.org, wexu2@cisco.com On Wed, Oct 20, 2010 at 07:55:56AM +0900, Isaku Yamahata wrote: > On Wed, Oct 20, 2010 at 12:40:49AM +0200, Michael S. Tsirkin wrote: > > > I think I suggested once a good way to implement this: > > > > - always make the bits w1c > > - after config write: > > if MHR is enabled, and you see that error log is not empty and that bit is 0, > > this means that someone has written 1b. > > so pop the first error from the log, and set bit to 1 if it's not empty. > > > > This way we only touch w1c mask on setup, no tricky range checks. > > Anything wrong with this approach? > > Basically okay. > Without the range checks, we need to restore the old value to the register > if 1b isn't written to the bit of the first error. > Probably you prefer restoring it mostly always than the range check. Well that would be consistent with how we handle config cycles in the rest of the code. We had a lot of tricky range checking code and we killed it all in favor of making operations idempotent so they are safe to redo on each config cycle. -- MST