From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTXVZ-0002IC-Ul for qemu-devel@nongnu.org; Wed, 31 Oct 2012 08:34:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTXVT-0002Rw-Sr for qemu-devel@nongnu.org; Wed, 31 Oct 2012 08:34:57 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:42039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTXVT-0002PC-LQ for qemu-devel@nongnu.org; Wed, 31 Oct 2012 08:34:51 -0400 Received: by mail-lb0-f173.google.com with SMTP id gj3so955491lbb.4 for ; Wed, 31 Oct 2012 05:34:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <50911ABA.4050003@redhat.com> References: <1348226255-4226-1-git-send-email-vasilis.liaskovitis@profitbricks.com> <1348226255-4226-6-git-send-email-vasilis.liaskovitis@profitbricks.com> <20121023122532.GE19977@stefanha-thinkpad.redhat.com> <50910848.7000002@redhat.com> <50911ABA.4050003@redhat.com> Date: Wed, 31 Oct 2012 13:34:49 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC PATCH v3 05/19] Implement dimm device abstraction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: blauwirbel@gmail.com, kvm@vger.kernel.org, gleb@redhat.com, seabios@seabios.org, liu ping fan , qemu-devel@nongnu.org, Vasilis Liaskovitis , kevin@koconnor.net, kraxel@redhat.com, anthony@codemonkey.ws, imammedo@redhat.com, Paolo Bonzini On Wed, Oct 31, 2012 at 1:34 PM, Avi Kivity wrote: > On 10/31/2012 02:18 PM, Stefan Hajnoczi wrote: >>> >>> IMO we should use the same mechanism as proposed for other devices: >>> address_space_map() should grab a reference on the dimm device, and >>> address_space_unmap() can release it. This way device destruction will >>> be deferred as soon as all devices complete I/O. >>> >>> We will have to be careful with network receive buffers though, since >>> they can be held indefinitely. >> >> Network receive buffers aren't mapped. Net receive is not zero-copy. >> For example, virtio-net does virtqueue_pop() inside >> virtio_net_receive(). >> >> I don't see a problem with networking. > > What about vhost-net? But that is managed separately with a MemoryListener. Yep. It should find out when memory regions change through its listener. Stefan