qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-2.5 1/1] vhost-user: do not send SET_VRING_E


From: Thibaut Collet
Subject: Re: [Qemu-devel] [PATCH for-2.5 1/1] vhost-user: do not send SET_VRING_ENABLE at start
Date: Tue, 24 Nov 2015 22:05:27 +0100

On Tue, Nov 24, 2015 at 9:52 PM, Michael S. Tsirkin <address@hidden> wrote:
> On Tue, Nov 24, 2015 at 05:10:36PM +0100, Thibaut Collet wrote:
>> This patch reverts partially commit 3a12f32229a.
>>
>> In case of live migration several queues can be enabled and not only the 
>> first
>> one. So inform backend that only the first queue is enabled is wrong.
>>
>> Since commit 7263a0ad7899 backend is already notified of the state of the 
>> vring
>> through the vring attach operation. This function, called during the startup
>> sequence, provides the correct state of the vring, even in case of live
>> migration.
>>
>> So nothing has to be added to give the vring state to the backend at the 
>> startup.
>>
>> Signed-off-by: Thibaut Collet <address@hidden>
>> ---
>>  hw/virtio/vhost.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
>> index 1794f0d..870cd12 100644
>> --- a/hw/virtio/vhost.c
>> +++ b/hw/virtio/vhost.c
>> @@ -1226,11 +1226,6 @@ int vhost_dev_start(struct vhost_dev *hdev, 
>> VirtIODevice *vdev)
>>          }
>>      }
>>
>> -    if (hdev->vhost_ops->vhost_set_vring_enable) {
>> -        /* only enable first vq pair by default */
>> -        hdev->vhost_ops->vhost_set_vring_enable(hdev, hdev->vq_index == 0);
>> -    }
>> -
>>      return 0;
>>  fail_log:
>>      vhost_log_put(hdev, false);
>> --
>> 2.1.4
>
> Yes - and I'm beginning to think that maybe we should revert
> all of 3a12f32229a then, for symmetry.
>

Keep the disable vring on the stop can be useful. For example if the
VM is rebooted all the vring will be disabled and backend will avoid
to send packet to the VM in this case (I am not sure the virtio ring
address is always valid during a reboot and writingg data in this
memory can cause unexpected behaviour in this case).

> Yunnan, Victor - what do you think?
>
> --
> MST



reply via email to

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