[Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function

[Michael S. Tsirkin]

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
>