From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdSeC-00013x-MN for qemu-devel@nongnu.org; Wed, 10 Sep 2008 12:34:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdSeC-00013c-8d for qemu-devel@nongnu.org; Wed, 10 Sep 2008 12:34:28 -0400 Received: from [199.232.76.173] (port=58145 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdSeB-00013Q-UI for qemu-devel@nongnu.org; Wed, 10 Sep 2008 12:34:27 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:41634) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdSeB-00081P-7O for qemu-devel@nongnu.org; Wed, 10 Sep 2008 12:34:27 -0400 Received: by gxk12 with SMTP id 12so13916542gxk.10 for ; Wed, 10 Sep 2008 09:34:26 -0700 (PDT) Message-ID: Date: Wed, 10 Sep 2008 19:34:25 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH v5 0/8] Add new firmware configuration mechanism In-Reply-To: <20080910153313.GI5924@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080908054204.19638.35292.stgit@gleb-debian.qumranet.com.qumranet.com> <48C7E7F7.2060600@codemonkey.ws> <20080910153313.GI5924@minantech.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org On 9/10/08, Gleb Natapov wrote: > On Wed, Sep 10, 2008 at 10:29:59AM -0500, Anthony Liguori wrote: > > Gleb Natapov wrote: > >> Hi, > >> > >> Here the latest version of the patch series. I hope now ready for inclusion. > >> > > > > Since Blue Swirl has been the most active in reviewing this series, I'm > > looking to him to decide when and to apply the series. AFAICT, it looks > > ready to go. > > > > I'll send a new version soon with the latest Blue Swirl addition of > write support and different IO ports for control and data. If the control port serves as status when read, we could introduce a status bit that indicates busy state, set if cur_offset != 0. It might solve the previously discussed multiple CPU boot access problem. But the status can be added later, it's not critical.