From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mattx-00069n-8v for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:08:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Matts-00066i-E9 for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:08:40 -0400 Received: from [199.232.76.173] (port=43700 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Matts-00066b-A7 for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:08:36 -0400 Received: from mail-gx0-f220.google.com ([209.85.217.220]:53104) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mattr-0000PK-Ss for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:08:36 -0400 Received: by gxk20 with SMTP id 20so12011599gxk.10 for ; Tue, 11 Aug 2009 09:08:35 -0700 (PDT) Message-ID: <4A819780.4040002@codemonkey.ws> Date: Tue, 11 Aug 2009 11:08:32 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function 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> In-Reply-To: <20090811134331.GA22661@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org 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. 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? Regards, Anthony Liguori