From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUCBa-0001XH-OZ for qemu-devel@nongnu.org; Fri, 02 Nov 2012 04:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUCBW-0001lT-9t for qemu-devel@nongnu.org; Fri, 02 Nov 2012 04:01:02 -0400 Received: from mout.web.de ([212.227.17.12]:57894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUCBV-0001lL-WC for qemu-devel@nongnu.org; Fri, 02 Nov 2012 04:00:58 -0400 Message-ID: <50937DB2.3040302@web.de> Date: Fri, 02 Nov 2012 09:00:50 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1351468127-15025-1-git-send-email-pingfank@linux.vnet.ibm.com> <1351468127-15025-6-git-send-email-pingfank@linux.vnet.ibm.com> <508E4D45.5060106@redhat.com> <50929902.9050002@redhat.com> <5092C2FF.5070909@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig807566C290655D17620807AE" Subject: Re: [Qemu-devel] [patch v5 5/8] memory: introduce local lock for address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Peter Maydell , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Avi Kivity , Anthony Liguori , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig807566C290655D17620807AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-11-02 01:52, liu ping fan wrote: > On Fri, Nov 2, 2012 at 2:44 AM, Jan Kiszka wrote: >> On 2012-11-01 16:45, Avi Kivity wrote: >>> On 10/29/2012 11:46 AM, liu ping fan wrote: >>>> On Mon, Oct 29, 2012 at 5:32 PM, Avi Kivity wrote: >>>>> On 10/29/2012 01:48 AM, Liu Ping Fan wrote: >>>>>> For those address spaces which want to be able out of big lock, th= ey >>>>>> will be protected by their own local. >>>>>> >>>>>> Signed-off-by: Liu Ping Fan >>>>>> --- >>>>>> memory.c | 11 ++++++++++- >>>>>> memory.h | 5 ++++- >>>>>> 2 files changed, 14 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/memory.c b/memory.c >>>>>> index 2f68d67..ff34aed 100644 >>>>>> --- a/memory.c >>>>>> +++ b/memory.c >>>>>> @@ -1532,9 +1532,15 @@ void memory_listener_unregister(MemoryListe= ner *listener) >>>>>> QTAILQ_REMOVE(&memory_listeners, listener, link); >>>>>> } >>>>>> >>>>>> -void address_space_init(AddressSpace *as, MemoryRegion *root) >>>>>> +void address_space_init(AddressSpace *as, MemoryRegion *root, boo= l lock) >>>>> >>>>> >>>>> Why not always use the lock? Even if the big lock is taken, it doe= sn't >>>>> hurt. And eventually all address spaces will be fine-grained. >>>>> >>>> I had thought only mmio is out of big lock's protection. While other= s >>>> address space will take extra expense. So leave them until they are >>>> ready to be out of big lock. >>> >>> The other address spaces are pio (which also needs fine-grained locki= ng) >>> and the dma address spaces (which are like address_space_memory, exce= pt >>> they are accessed via DMA instead of from the vcpu). >> >> The problem is with memory regions that don't do fine-grained locking >> yet, thus don't provide ref/unref. Then we fall back to taking BQL >> across dispatch. If the dispatch caller already holds the BQL, we will= >> bail out. >> > Yes, these asymmetrice callers are bothering. Currently, I just make > exceptions for them, and would like to make the biglock recursive. > But this motivation may make bug not easy to find. >=20 >> As I understand the series, as->lock =3D=3D NULL means that we will ne= ver >> take any lock during dispatch as the caller is not yet ready for >> fine-grained locking. This prevents the problem - for PIO at least. Bu= t >> this series should break TCG as it calls into MMIO dispatch from the >> VCPU while holding the BQL. >> > What about add another condition "dispatch_type =3D=3D DISPATCH_MMIO" t= o > tell this situation. An alternative pattern that we will also use for core services is to provide an additional entry point, one that indicates that the caller doesn't hold the BQL. Then we will gradually move things over until the existing entry point is obsolete. Jan --------------enig807566C290655D17620807AE 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/ iEYEARECAAYFAlCTfbIACgkQitSsb3rl5xS+pwCg0XOUWkeDcRAfXDRdmMBSHTg2 8hQAn2K5C9iihx0PPM5bhdtT2GwHeNWo =Krli -----END PGP SIGNATURE----- --------------enig807566C290655D17620807AE--