From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T5ufp-0002vF-JX for qemu-devel@nongnu.org; Mon, 27 Aug 2012 04:27:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T5ufj-00010A-In for qemu-devel@nongnu.org; Mon, 27 Aug 2012 04:27:53 -0400 Received: from mout.web.de ([212.227.15.4]:57323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T5ufj-0000zv-91 for qemu-devel@nongnu.org; Mon, 27 Aug 2012 04:27:47 -0400 Message-ID: <503B2F7A.5040502@web.de> Date: Mon, 27 Aug 2012 10:27:38 +0200 From: Jan Kiszka 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> <503B1B4B.6050108@redhat.com> <503B260E.70607@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDD977C803E5CA456B49F6D48" Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Paolo Bonzini , Liu Ping Fan , qemu-devel@nongnu.org, Anthony Liguori , Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD977C803E5CA456B49F6D48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-08-27 10:17, liu ping fan wrote: > On Mon, Aug 27, 2012 at 3:47 PM, Jan Kiszka wrote: >> On 2012-08-27 09:01, Paolo Bonzini wrote: >>> Il 25/08/2012 09:42, liu ping fan ha scritto: >>>>>> >>>>>> I don't see why MMIO dispatch should hold the IDEBus ref rather th= an the >>>>>> PCIIDEState. >>>>>> >>>> When transfer memory_region_init_io() 3rd para from void* opaque to= >>>> Object* obj, the obj : opaque is not neccessary 1:1 map. For such >>>> situation, in order to let MemoryRegionOps tell between them, we >>>> should pass PCIIDEState->bus[0], bus[1] separately. >>> >>> The rule should be that the obj is the object that you want reference= d, >>> and that should be the PCIIDEState. >>> >>> But this is anyway moot because it only applies to objects that are >>> converted to use unlocked dispatch. This likely will not be the case= >>> for IDE. >> >> BTW, I'm pretty sure - after implementing the basics for BQL-free PIO >> dispatching - that device objects are the wrong target for reference >=20 > Hi Jan, thanks for reminder, but could you explain it more detail? > mmio dispatch table holds 1 ref for device, before releasing this > ref,( When unplugging, we detach all the device's mr from memory, then > drop the ref. So I think that no leak will be exposed by mr and it is > safe to use device as target for reference. It would be a mistake to assume that memory regions can only be embedded in device objects. Memory regions can be reconfigured or dynamically added/removed (see e.g. portio lists) - there is no "device" in this sentence. Regions are stored in the dispatching table, they will first of all be touched without holding the BQL. So their content has to be stable in that period, and it is the proper abstraction, IMHO, to focus on their life cycle management and attach all the rest to them. >=20 >> counting. We keep memory regions in our dispatching tables (PIO >> dispatching needs some refactoring for this), and those regions need >> protection for BQL-free use. Devices can't pass away as long as the ha= ve > Yes, it is right. Device can pass away only after mr removed from > dispatching tables Great, then you don't have to worry about device objects in the context of dispatching. Jan --------------enigDD977C803E5CA456B49F6D48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA7L3oACgkQitSsb3rl5xQsVACePeHwIbg3t8DHlVfe8Z7cXV1M n1YAoKy52f3aIRxCtdLlKobt+cHMHCrI =PJX5 -----END PGP SIGNATURE----- --------------enigDD977C803E5CA456B49F6D48--