From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MauCA-0003Zg-7g for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:27:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MauC5-0003ZG-FC for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:27:29 -0400 Received: from [199.232.76.173] (port=56676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MauC5-0003ZC-BA for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:27:25 -0400 Received: from mx2.redhat.com ([66.187.237.31]:55969) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MauC4-0004Gm-TP for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:27:25 -0400 Date: Tue, 11 Aug 2009 19:25:37 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function Message-ID: <20090811162537.GA25705@redhat.com> References: <20090810192809.GA16800@redhat.com> <4A8076F0.5050700@codemonkey.ws> <20090810194753.GA16803@redhat.com> <4A808437.8040307@codemonkey.ws> <20090810221940.GB17099@redhat.com> <4A80A0A1.2020905@codemonkey.ws> <20090811084807.GA3029@redhat.com> <4A816EEB.4070707@codemonkey.ws> <20090811134331.GA22661@redhat.com> <4A819780.4040002@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A819780.4040002@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org On Tue, Aug 11, 2009 at 11:08:32AM -0500, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >>> Let's say we supported virtio-vbus along with virtio-pci. What does >>> virtio_blk_get_features() do to mask out sg_indirect? For all >>> virtio-blk knows, it could be on top of virtio-vbus. >>> >> >> So? VIRTIO_RING_F_INDIRECT_DESC applies to all transports. >> Just clear this bit. >> > > You can have many layers with virtio. device + transport + ring > > virtio-vbus would have a different transport and a different ring > implementation. So no, VIRTIO_RING_F_INDIRECT_DESC wouldn't apply to > virtio-vbus. > >>>> This would break things like >>>> migrating between userspace and kernel virtio (something that I >>>> support). >>>> >>> The PIT uses a common state structure and common code for >>> save/restore. This makes migration compatible. >>> >> >> Isn't device name put in the machine config, which presumably is >> send along as well? >> > > Good question. I don't know the best way to resolve this. > > Maybe migration between devices isn't such a good idea. It's > conceivable that vhost will require some state that isn't present in the > userspace virtio-net. It can't. It switches to userspace before migration. > I think this requires some thought. > >>> In this case, it's two separate implementations of the same device. >>> I think it makes sense for them to be separate devices. >>> >>> Regards, >>> >>> Anthony Liguori >>> >> >> Hmm, I see what you mean. But kernel virtio is harder. Unlike >> PIT/APIC, it is not a separate codepath. It still needs >> all of userspace virtio to support live migration and non-MSI guests. >> Really, it's the same device that switches between kernel and userspace >> modes on the fly. >> >> This will become clearer from code when I implement migration for vhost, >> but basically you switch to userspace when you start migration, and >> back to kernel if migration fails. You also switch to kernel when MSI >> is enabled and back to userspace when it is disabled. >> > > Why bother switching to userspace for migration? Can't you just have > get/set ioctls for the state? I have these. But live migration requires dirty page logging. I do not want to implement it in kernel. > Regards, > > Anthony Liguori >