From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51129)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VLsRh-0007HZ-C6
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 06:23:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VLsRY-0000QA-UQ
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 06:23:49 -0400
Received: from mail-qa0-x232.google.com ([2607:f8b0:400d:c00::232]:57887)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1VLsRY-0000Q3-Pd
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 06:23:40 -0400
Received: by mail-qa0-f50.google.com with SMTP id j7so1811532qaq.9
	for <qemu-devel@nongnu.org>; Tue, 17 Sep 2013 03:23:39 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <52382DB4.8080409@redhat.com>
Date: Tue, 17 Sep 2013 12:23:48 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1378211609-16121-1-git-send-email-pbonzini@redhat.com>
	<1378211609-16121-3-git-send-email-pbonzini@redhat.com>
	<20130917091657.GB18186@redhat.com> <52382738.70802@redhat.com>
In-Reply-To: <52382738.70802@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 02/38] pci: split exit and finalize
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: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>

Il 17/09/2013 11:56, Paolo Bonzini ha scritto:
> Yes.  do_pci_unregister_device marks the point where the guest will not
> be able to submit new requests to the device, but there may be previous
> requests pending. because you could have something like this:

Michael pointed out offlist that the previous example involved the
address_space_map bounce buffer.

Here is a simpler one that doesn't rely on it:

       VCPU 1                    VCPU 2
       ----------------------------------------------------
       start asynchronous I/O
        pci_dma_sglist_init
         object_ref
       ** releases BQL
                                  eject device
                                   object_unparent
                                    my_device_exit
                                     memory_region_del_subregion
                                     ** cannot yet destroy!!
                                     ** address_space_unmap will use it
       ** gets BQL again
       asynchronous I/O ends
        qemu_sglist_destroy
         object_unref
          instance_finalize

Paolo