public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Si-Wei Liu <si-wei.liu@oracle.com>
To: Eugenio Perez Martin <eperezma@redhat.com>,
	Dragos Tatulea <dtatulea@nvidia.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	virtualization@lists.linux-foundation.org,
	Gal Pressman <gal@nvidia.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Parav Pandit <parav@nvidia.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: Re: [PATCH vhost v2 4/8] vdpa/mlx5: Mark vq addrs for modification in hw vq
Date: Tue, 12 Dec 2023 15:44:00 -0800	[thread overview]
Message-ID: <27312106-07b9-4719-970c-b8e1aed7c4eb@oracle.com> (raw)
In-Reply-To: <CAJaqyWeEY9LNTE8QEnJgLhgS7HiXr5gJEwwPBrC3RRBsAE4_7Q@mail.gmail.com>



On 12/12/2023 11:21 AM, Eugenio Perez Martin wrote:
> On Tue, Dec 5, 2023 at 11:46 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
>> Addresses get set by .set_vq_address. hw vq addresses will be updated on
>> next modify_virtqueue.
>>
>> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
>> Reviewed-by: Gal Pressman <gal@nvidia.com>
>> Acked-by: Eugenio Pérez <eperezma@redhat.com>
> I'm kind of ok with this patch and the next one about state, but I
> didn't ack them in the previous series.
>
> My main concern is that it is not valid to change the vq address after
> DRIVER_OK in VirtIO, which vDPA follows. Only memory maps are ok to
> change at this moment. I'm not sure about vq state in vDPA, but vhost
> forbids changing it with an active backend.
>
> Suspend is not defined in VirtIO at this moment though, so maybe it is
> ok to decide that all of these parameters may change during suspend.
> Maybe the best thing is to protect this with a vDPA feature flag.
I think protect with vDPA feature flag could work, while on the other 
hand vDPA means vendor specific optimization is possible around suspend 
and resume (in case it helps performance), which doesn't have to be 
backed by virtio spec. Same applies to vhost user backend features, 
variations there were not backed by spec either. Of course, we should 
try best to make the default behavior backward compatible with 
virtio-based backend, but that circles back to no suspend definition in 
the current virtio spec, for which I hope we don't cease development on 
vDPA indefinitely. After all, the virtio based vdap backend can well 
define its own feature flag to describe (minor difference in) the 
suspend behavior based on the later spec once it is formed in future.

Regards,
-Siwei



>
> Jason, what do you think?
>
> Thanks!
>
>> ---
>>   drivers/vdpa/mlx5/net/mlx5_vnet.c  | 9 +++++++++
>>   include/linux/mlx5/mlx5_ifc_vdpa.h | 1 +
>>   2 files changed, 10 insertions(+)
>>
>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> index f8f088cced50..80e066de0866 100644
>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> @@ -1209,6 +1209,7 @@ static int modify_virtqueue(struct mlx5_vdpa_net *ndev,
>>          bool state_change = false;
>>          void *obj_context;
>>          void *cmd_hdr;
>> +       void *vq_ctx;
>>          void *in;
>>          int err;
>>
>> @@ -1230,6 +1231,7 @@ static int modify_virtqueue(struct mlx5_vdpa_net *ndev,
>>          MLX5_SET(general_obj_in_cmd_hdr, cmd_hdr, uid, ndev->mvdev.res.uid);
>>
>>          obj_context = MLX5_ADDR_OF(modify_virtio_net_q_in, in, obj_context);
>> +       vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, virtio_q_context);
>>
>>          if (mvq->modified_fields & MLX5_VIRTQ_MODIFY_MASK_STATE) {
>>                  if (!is_valid_state_change(mvq->fw_state, state, is_resumable(ndev))) {
>> @@ -1241,6 +1243,12 @@ static int modify_virtqueue(struct mlx5_vdpa_net *ndev,
>>                  state_change = true;
>>          }
>>
>> +       if (mvq->modified_fields & MLX5_VIRTQ_MODIFY_MASK_VIRTIO_Q_ADDRS) {
>> +               MLX5_SET64(virtio_q, vq_ctx, desc_addr, mvq->desc_addr);
>> +               MLX5_SET64(virtio_q, vq_ctx, used_addr, mvq->device_addr);
>> +               MLX5_SET64(virtio_q, vq_ctx, available_addr, mvq->driver_addr);
>> +       }
>> +
>>          MLX5_SET64(virtio_net_q_object, obj_context, modify_field_select, mvq->modified_fields);
>>          err = mlx5_cmd_exec(ndev->mvdev.mdev, in, inlen, out, sizeof(out));
>>          if (err)
>> @@ -2202,6 +2210,7 @@ static int mlx5_vdpa_set_vq_address(struct vdpa_device *vdev, u16 idx, u64 desc_
>>          mvq->desc_addr = desc_area;
>>          mvq->device_addr = device_area;
>>          mvq->driver_addr = driver_area;
>> +       mvq->modified_fields |= MLX5_VIRTQ_MODIFY_MASK_VIRTIO_Q_ADDRS;
>>          return 0;
>>   }
>>
>> diff --git a/include/linux/mlx5/mlx5_ifc_vdpa.h b/include/linux/mlx5/mlx5_ifc_vdpa.h
>> index b86d51a855f6..9594ac405740 100644
>> --- a/include/linux/mlx5/mlx5_ifc_vdpa.h
>> +++ b/include/linux/mlx5/mlx5_ifc_vdpa.h
>> @@ -145,6 +145,7 @@ enum {
>>          MLX5_VIRTQ_MODIFY_MASK_STATE                    = (u64)1 << 0,
>>          MLX5_VIRTQ_MODIFY_MASK_DIRTY_BITMAP_PARAMS      = (u64)1 << 3,
>>          MLX5_VIRTQ_MODIFY_MASK_DIRTY_BITMAP_DUMP_ENABLE = (u64)1 << 4,
>> +       MLX5_VIRTQ_MODIFY_MASK_VIRTIO_Q_ADDRS           = (u64)1 << 6,
>>          MLX5_VIRTQ_MODIFY_MASK_DESC_GROUP_MKEY          = (u64)1 << 14,
>>   };
>>
>> --
>> 2.42.0
>>


  parent reply	other threads:[~2023-12-12 23:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 10:46 [PATCH vhost v2 0/8] vdpa/mlx5: Add support for resumable vqs Dragos Tatulea
2023-12-05 10:46 ` [PATCH mlx5-vhost v2 1/8] vdpa/mlx5: Expose resumable vq capability Dragos Tatulea
2023-12-05 10:46 ` [PATCH vhost v2 2/8] vdpa/mlx5: Allow modifying multiple vq fields in one modify command Dragos Tatulea
2023-12-05 10:46 ` [PATCH vhost v2 3/8] vdpa/mlx5: Introduce per vq and device resume Dragos Tatulea
2023-12-05 10:46 ` [PATCH vhost v2 4/8] vdpa/mlx5: Mark vq addrs for modification in hw vq Dragos Tatulea
2023-12-12 19:21   ` Eugenio Perez Martin
2023-12-12 19:44     ` Dragos Tatulea
2023-12-12 23:44     ` Si-Wei Liu [this message]
2023-12-14 13:39       ` Dragos Tatulea
2023-12-14 13:45         ` Michael S. Tsirkin
2023-12-14 15:51           ` Dragos Tatulea
2023-12-14 18:30             ` Eugenio Perez Martin
2023-12-15 12:35               ` Dragos Tatulea
2023-12-15 14:13                 ` Dragos Tatulea
2023-12-15 17:56                   ` Eugenio Perez Martin
2023-12-16 11:03                     ` Dragos Tatulea
2023-12-18 10:16                       ` Eugenio Perez Martin
2023-12-18 10:52                         ` Dragos Tatulea
2023-12-18 12:06                           ` Eugenio Perez Martin
2023-12-18 13:58                             ` Dragos Tatulea
2023-12-19  7:24                               ` Eugenio Perez Martin
2023-12-19 11:16                                 ` Dragos Tatulea
2023-12-19 14:02                                   ` Eugenio Perez Martin
2023-12-19 15:11                                     ` Dragos Tatulea
2023-12-05 10:46 ` [PATCH vhost v2 5/8] vdpa/mlx5: Mark vq state " Dragos Tatulea
2023-12-05 10:46 ` [PATCH vhost v2 6/8] vdpa/mlx5: Use vq suspend/resume during .set_map Dragos Tatulea
2023-12-12 19:22   ` Eugenio Perez Martin
2023-12-05 10:46 ` [PATCH vhost v2 7/8] vdpa/mlx5: Introduce reference counting to mrs Dragos Tatulea
2023-12-12 18:26   ` Eugenio Perez Martin
2023-12-05 10:46 ` [PATCH vhost v2 8/8] vdpa/mlx5: Add mkey leak detection Dragos Tatulea
2023-12-12 18:32   ` Eugenio Perez Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27312106-07b9-4719-970c-b8e1aed7c4eb@oracle.com \
    --to=si-wei.liu@oracle.com \
    --cc=dtatulea@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=gal@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox