From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXx5w-0005Pt-FR for qemu-devel@nongnu.org; Thu, 02 May 2013 13:15:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXx5v-0004Dm-5g for qemu-devel@nongnu.org; Thu, 02 May 2013 13:15:00 -0400 Received: from david.siemens.de ([192.35.17.14]:31083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXx5u-0004DX-S9 for qemu-devel@nongnu.org; Thu, 02 May 2013 13:14:59 -0400 Message-ID: <51829F0E.6060200@siemens.com> Date: Thu, 02 May 2013 19:14:54 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1353808984-22368-1-git-send-email-qemulist@gmail.com> <51829B30.7020308@siemens.com> In-Reply-To: <51829B30.7020308@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 0/7] push mmio dispatch out of big lock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , "gleb@redhat.com" , Stefan Hajnoczi , Marcelo Tosatti , "qemu-devel@nongnu.org" , Anthony Liguori , Paolo Bonzini On 2013-05-02 18:58, Jan Kiszka wrote: > Hi Pingfan, > > On 2012-12-06 08:28, liu ping fan wrote: >> Any suggestion? Or new design idea for this? > > Finally... I'm getting back to this. I'm currently trying to make use of > this series, adapting it to my needs (selective BQL-free dispatching of > PIO regions). > > Is there a newer version available on your side? This one obviously no > longer applies due to all the code movements in QEMU. But it also seems > to contain some bugs, at least in patch 5 (mixed up page number vs. page > address around for address_space_section_lookup_ref). Oh, and the series isn't bisectable between 5 and 7. Jan > > Then we should get rid of the ref/unref callbacks. Making a memory > region BQL-free must be as simple as setting a flag or (more likely) > adding a reference to the owning QOM object in the region. > Reimplementing ref/unref in device models over and over again is clearly > a no-go. Maybe I'm currently forgetting a use case where overloading the > reference functions is needed, so please help my memory in that case. > > Jan > -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux