search for: mlx5_vdpa_warn

...\ > + mlx5_vdpa_info(mvdev, "%s\n", #_status); \ > + } while (0) > + > +static void print_status(struct mlx5_vdpa_dev *mvdev, u8 status, bool set) > +{ > + if (status & ~VALID_STATUS_MASK) > + mlx5_vdpa_warn(mvdev, "Warning: there are invalid status bits 0x%x\n", > + status & ~VALID_STATUS_MASK); > + > + if (!mlx5_vdpa_debug) > + return; > + > + mlx5_vdpa_info(mvdev, "driver status %s", set ? "set" : "get"); > + if (set &&am...

...0676a6..74264e59 100644 --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c @@ -1133,15 +1133,17 @@ static void suspend_vq(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *m if (!mvq->initialized) return; - if (query_virtqueue(ndev, mvq, &attr)) { - mlx5_vdpa_warn(&ndev->mvdev, "failed to query virtqueue\n"); - return; - } if (mvq->fw_state != MLX5_VIRTIO_NET_Q_OBJECT_STATE_RDY) return; if (modify_virtqueue(ndev, mvq, MLX5_VIRTIO_NET_Q_OBJECT_STATE_SUSPEND)) mlx5_vdpa_warn(&ndev->mvdev, "modify to suspend failed\n...

...ruct mlx5_vdpa_dev *mvdev, struct vhost_iotlb *iotlb, unsigned int asid); void mlx5_vdpa_destroy_mr(struct mlx5_vdpa_dev *mvdev); void mlx5_vdpa_destroy_mr_asid(struct mlx5_vdpa_dev *mvdev, unsigned int asid); +int mlx5_vdpa_reset_mr(struct mlx5_vdpa_dev *mvdev, unsigned int asid); #define mlx5_vdpa_warn(__dev, format, ...) \ dev_warn((__dev)->mdev->device, "%s:%d:(pid %d) warning: " format, __func__, __LINE__, \ diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 5a1971fc..ec2c7b4e1 100644 --- a/...

...X5_ST_SZ_BYTES(query_hca_cap_out); + out = kzalloc(out_size, GFP_KERNEL); + if (!out) + return -ENOMEM; + + MLX5_SET(query_hca_cap_in, in, opcode, MLX5_CMD_OP_QUERY_HCA_CAP); + MLX5_SET(query_hca_cap_in, in, op_mod, opmod); + err = mlx5_cmd_exec_inout(mdev, query_hca_cap, in, out); + if (err) { + mlx5_vdpa_warn(&ndev->mvdev, + "Failed reading vdpa umem capabilities with err %d\n", err); + goto out; + } + + caps = MLX5_ADDR_OF(query_hca_cap_out, out, capability); + + ndev->umem_1_buffer_param_a = MLX5_GET(virtio_emulation_cap, caps, umem_1_buffer_param_a); + ndev->umem_1_buffer_p...

...vqs[idx]; >>> + int err; >>> + >>> + if (!mvq->ready && ready && mvq->fw_state != MLX5_VIRTIO_NET_Q_OBJECT_STATE_RDY) { >>> + err = modify_virtqueue(ndev, mvq, MLX5_VIRTIO_NET_Q_OBJECT_STATE_RDY); >>> + if (err) { >>> + mlx5_vdpa_warn(mvdev, "failed to modify virtqueue(%d)\n", err); >>> + return; >>> + } >>> + } >> >> I wonder what's the reason of changing vq state on the hardware >> here. I think we can defer it to set_status(). >> > I can defer this to set...

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

...t;>>> + >>>>> + if (!mvq->ready && ready && mvq->fw_state != MLX5_VIRTIO_NET_Q_OBJECT_STATE_RDY) { >>>>> + err = modify_virtqueue(ndev, mvq, MLX5_VIRTIO_NET_Q_OBJECT_STATE_RDY); >>>>> + if (err) { >>>>> + mlx5_vdpa_warn(mvdev, "failed to modify virtqueue(%d)\n", err); >>>>> + return; >>>>> + } >>>>> + } >>>> I wonder what's the reason of changing vq state on the hardware >>>> here. I think we can defer it to set_status(). >&gt...

This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix

This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix

...rt, mr->end - 1); 251 map; map = vhost_iotlb_itree_next(map, mr->start, mr->end - 1)) { 252 paend = map->addr + maplen(map, mr); 253 for (pa = map->addr; pa < paend; pa += sglen) { > 254 pg = pfn_to_page(__phys_to_pfn(pa)); 255 if (!sg) { 256 mlx5_vdpa_warn(mvdev, "sg null. start 0x%llx, end 0x%llx\n", 257 map->start, map->last + 1); 258 err = -ENOMEM; 259 goto err_map; 260 } 261 sg_set_page(sg, pg, sglen, 0); 262 sg = sg_next(sg); 263 if (!sg) 264 goto done; 265 } 266...

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA: