From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56753)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TQdDk-0008BY-G0
	for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:04:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TQdDj-0000wF-H5
	for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:04:32 -0400
Received: from goliath.siemens.de ([192.35.17.28]:15156)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TQdDj-0000w6-7h
	for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:04:31 -0400
Message-ID: <508687C4.4030109@siemens.com>
Date: Tue, 23 Oct 2012 14:04:20 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1350897839-29593-1-git-send-email-pingfank@linux.vnet.ibm.com>
	<1350897839-29593-6-git-send-email-pingfank@linux.vnet.ibm.com>
	<5085140F.2070603@redhat.com> <508684BE.1080103@redhat.com>
	<508685C0.60700@redhat.com>
In-Reply-To: <508685C0.60700@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref,
	unref interface for MemoryRegionOps
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Liu Ping Fan <pingfank@linux.vnet.ibm.com>, Stefan Hajnoczi <stefanha@gmail.com>, Marcelo Tosatti <mtosatti@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Anthony Liguori <anthony@codemonkey.ws>, Paolo Bonzini <pbonzini@redhat.com>

On 2012-10-23 13:55, Avi Kivity wrote:
> On 10/23/2012 01:51 PM, Paolo Bonzini wrote:
>> Il 22/10/2012 11:38, Avi Kivity ha scritto:
>>>>>  
>>>>>  typedef struct MemoryRegionOps MemoryRegionOps;
>>>>>  typedef struct MemoryRegion MemoryRegion;
>>>>> @@ -66,6 +67,8 @@ struct MemoryRegionOps {
>>>>>                    target_phys_addr_t addr,
>>>>>                    uint64_t data,
>>>>>                    unsigned size);
>>>>> +    int (*ref)(MemoryRegion *mr);
>>>>> +    void (*unref)(MemoryRegion *mr);
>>>>>  
>>> Why return an int?  Should succeed unconditionally.  Please fold into 7
>>> (along with 6).
>>
>> So the stop_machine idea is thrown away?  
> 
> IIRC I convinced myself that it's just as bad.

One tricky part with stop machine is that legacy code may trigger it
while holding the BQL, does not expect to lose that lock even for a
brief while, but synchronizing on other threads does require dropping
the lock right now. Maybe an implementation detail, but at least a nasty
one.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux