[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function
Date: Tue, 11 Aug 2009 19:25:37 +0300
User-agent: Mutt/1.5.19 (2009-01-05)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]