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