From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TftLa-0006nV-Rb for qemu-devel@nongnu.org; Tue, 04 Dec 2012 09:19:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TftLT-0004Uy-5N for qemu-devel@nongnu.org; Tue, 04 Dec 2012 09:19:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TftLS-0004UF-UB for qemu-devel@nongnu.org; Tue, 04 Dec 2012 09:19:35 -0500 Date: Tue, 4 Dec 2012 15:19:30 +0100 From: Stefan Hajnoczi Message-ID: <20121204141930.GA17453@stefanha-thinkpad.redhat.com> References: <1353597412-12232-1-git-send-email-stefanha@redhat.com> <1353597412-12232-12-git-send-email-stefanha@redhat.com> <20121129131235.GA9625@redhat.com> <20121129144555.GB14196@stefanha-thinkpad.redhat.com> <20121129145548.GB10896@redhat.com> <20121204112020.GA9528@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121204112020.GA9528@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 11/11] virtio-blk: add x-data-plane=on|off performance feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org, Blue Swirl , khoa@us.ibm.com, Paolo Bonzini , Asias He On Tue, Dec 04, 2012 at 01:20:20PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 29, 2012 at 04:55:48PM +0200, Michael S. Tsirkin wrote: > > On Thu, Nov 29, 2012 at 03:45:55PM +0100, Stefan Hajnoczi wrote: > > > On Thu, Nov 29, 2012 at 03:12:35PM +0200, Michael S. Tsirkin wrote: > > > > On Thu, Nov 22, 2012 at 04:16:52PM +0100, Stefan Hajnoczi wrote: > > > > > The virtio-blk-data-plane feature is easy to integrate into > > > > > hw/virtio-blk.c. The data plane can be started and stopped similar to > > > > > vhost-net. > > > > > > > > > > Users can take advantage of the virtio-blk-data-plane feature using the > > > > > new -device virtio-blk-pci,x-data-plane=on property. > > > > > > > > > > The x-data-plane name was chosen because at this stage the feature is > > > > > experimental and likely to see changes in the future. > > > > > > > > > > If the VM configuration does not support virtio-blk-data-plane an error > > > > > message is printed. Although we could fall back to regular virtio-blk, > > > > > I prefer the explicit approach since it prompts the user to fix their > > > > > configuration if they want the performance benefit of > > > > > virtio-blk-data-plane. > > > > > > > > Not only that, this affects features exposed to guest so it really can't be > > > > trasparent. > > > > > > > > Which reminds me - shouldn't some features be turned off? > > > > For example, VIRTIO_BLK_F_SCSI? > > > > > > Yes, virtio-blk-data-plane only starts when you give -device > > > virtio-blk-pci,scsi=off,x-data-plane=on. If you use scsi=on an error > > > message is printed. > > > > > > > > Limitations: > > > > > * Only format=raw is supported > > > > > * Live migration is not supported > > > > > > > > This is probably fixable long term? > > > > > > Absolutely. There are two parts: > > > > > > 1. Marking written memory dirty so live RAM migration can work. Missing > > > today, easy cheat is to switch off virtio-blk-data-plane and silently > > > switch to regular virtio-blk emulation while memory dirty logging is > > > enabled. The more long-term solution is to actually communicate the > > > dirty information back to the memory API. > > > > > > 2. Synchronizing virtio-blk-data-plane vring state with virtio-blk so > > > save/load works. This should be relatively straightforward. > > > > > > I don't want to gate this patch series on live migration support but it > > > is on my TODO list for virtio-blk-data-plane after this initial series > > > has been merged. > > > > > > > > * Block jobs, hot unplug, and other operations fail with -EBUSY > > > > > > > > Hmm I don't see code to disable PCU unplug in this patch. > > > > I expected no_hotplug to be set. > > > > Where is it? > > > > > > It uses the bdrv_in_use() mechanism. > > > > Hmm but PCI device can still go away if > > guest ejects it. Does this work fine? > > Any comment? Sorry for the delay. virtio_blk_exit() is called when the device is freed. The code destroys the data plane thread - this includes draining requests and then terminating the thread. I tested with pci_del so the guest is cooperating but virtio_blk_exit() does not assume that the data plane thread is already stopped. Is this what you were asking? Stefan