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 > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
