Virtualization - Aug 2021 - [PATCH v4 5/6] vdpa/mlx5: Add support for control VQ and MAC setting

? 2021/8/24 ??8:59, Eugenio Perez Martin ??:
>> @@ -1378,11 +1508,19 @@ static int mlx5_vdpa_set_vq_address(struct
vdpa_device *vdev, u16 idx, u64 desc_
>>   {
>>          struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
>>          struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
>> -       struct mlx5_vdpa_virtqueue *mvq = &ndev->vqs[idx];
>> +       struct mlx5_vdpa_virtqueue *mvq;
>>
>>          if (!is_index_valid(mvdev, idx))
>>                  return -EINVAL;
>>
>> +       if (is_ctrl_vq_idx(mvdev, idx)) {
>> +               mvdev->cvq.desc_addr = desc_area;
>> +               mvdev->cvq.device_addr = device_area;
>> +               mvdev->cvq.driver_addr = driver_area;
> Hi Eli,
>
> Some mechanism for updating vringh addresses is also needed here.
> setup_virtqueues is called a lot earlier than cvq address set, and
> when cvq is kicked it tries to read from an outdated/invalid address.

Hi Eugenio:

Usually the driver should set the cvq address before set DRIVER_OK.

And during DRIVER_OK the mlx5 driver will call setup_virtqueues().

Did you see the cvq is set after DRIVER_OK?

Thanks

>
> In my environment I just set mvdev->cvq.vring.vring.{desc,avail,used}
> as a workaround and then I have cvq, but I think more protection is
> needed because of the workqueue.
>
> Sorry for the dripping of comments, it took a while to know what was
> failing in the environment.
>
> Thanks!
>