在 2021/8/11 下午3:53, Eli Cohen 写道:
One thing need to solve for mq is that the:
+static u16 ctrl_vq_idx(struct mlx5_vdpa_dev *mvdev)
+{
+ return 2 * mlx5_vdpa_max_qps(mvdev->max_vqs);
+}
We should handle the case when MQ is supported by the device but not the
driver.
E.g in the case when we have 2 queue pairs:
When MQ is enabled, cvq is queue 4
When MQ is not enabled, cvq is queue 2
There's some issue with this. I get callbacks targeting specific
virtqueues before features negotiation has been completed.
Specifically, I get set_vq_cb() calls. At this point I must know the
control vq index.
So I think we need do both:
1) At one hand, it's a bug for the userspace to use vq_index before
feature is negotiated
(looks like a bug in my cvq series that will call SET_VRING_CALL before
feature is negotiate, which I will look).
2) At the other hand, the driver should be able to deal with that
I think the CVQ index must not depend on the negotiated features but
rather depend of the value the device driver provides in the call to
_vdpa_register_device().
At the virtio level, it's too late to change that and it breaks the
backward compatibility.
But at the vDPA level, the under layer device can map virtio cvq to any
of it's virtqueue.
E.g map cvq (index 2) to mlx5 cvq (the last).
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
