From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55689)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T63kz-0001b5-Sj
	for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:09:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T63ky-000895-J6
	for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:09:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:64150)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1T63ky-00088L-B0
	for qemu-devel@nongnu.org; Mon, 27 Aug 2012 14:09:48 -0400
Message-ID: <503BB7E7.4050709@redhat.com>
Date: Mon, 27 Aug 2012 11:09:43 -0700
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1345801763-24227-1-git-send-email-qemulist@gmail.com>
	<1345801763-24227-11-git-send-email-qemulist@gmail.com>
	<503792F1.4090109@redhat.com>
	<CAJnKYQk2zDFiCmr3Qo=Cj4B21oWd0FoC8c2N3OG3ujm=pMoD9Q@mail.gmail.com>
	<503B1B4B.6050108@redhat.com> <503B260E.70607@web.de>
	<503BA9BC.5010207@redhat.com> <503BAAF0.2020103@siemens.com>
In-Reply-To: <503BAAF0.2020103@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life
	cycle problem
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: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Liu Ping Fan <pingfank@linux.vnet.ibm.com>, liu ping fan <qemulist@gmail.com>, Anthony Liguori <anthony@codemonkey.ws>, qemu-devel@nongnu.org

On 08/27/2012 10:14 AM, Jan Kiszka wrote:
> > 
> > Deregistration is fine, the problem is destruction.
> > 
>
> It isn't as you access memory region states that can change after
> deregistration. Devices can remove memory regions from the mapping,
> alter and then reinsert them. The last to steps must not happen while
> anyone is still using a reference to that region.
>

Why not?  If the guest is accessing an mmio region while reconfiguring
it in a way that changes its meaning, either the previous or the next
meaning is valid.

It is true that memory_region_set_enabled(..., false) will become weaker
as a result.  Code will have to be prepared for that.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.