We need to tell in the caller, as some errors are expected in a normal
workflow.  In particular, parent drivers in recent kernels with
VHOST_BACKEND_F_IOTLB_ASID may not support vring groups.  In that case,
-ENOTSUP is returned.

This is the case of vp_vdpa in Linux 6.2.

Next patches in this series will use that information to know if it must
abort or not.

Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
---
 net/vhost-vdpa.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 99904a0da7..4397c0d4b3 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -361,6 +361,14 @@ static NetClientInfo net_vhost_vdpa_info = {
         .check_peer_type = vhost_vdpa_check_peer_type,
 };
 
+/**
+ * Get vring virtqueue group
+ *
+ * @device_fd  vdpa device fd
+ * @vq_index   Virtqueue index
+ *
+ * Return -errno in case of error, or vq group if success.
+ */
 static int64_t vhost_vdpa_get_vring_group(int device_fd, unsigned vq_index)
 {
     struct vhost_vring_state state = {
@@ -369,6 +377,7 @@ static int64_t vhost_vdpa_get_vring_group(int device_fd, unsigned vq_index)
     int r = ioctl(device_fd, VHOST_VDPA_GET_VRING_GROUP, &state);
 
     if (unlikely(r < 0)) {
+        r = -errno;
         error_report("Cannot get VQ %u group: %s", vq_index,
                      g_strerror(errno));
         return r;
-- 
2.31.1

On Fri, Mar 17, 2023 at 03:55:40PM +0100, Eugenio Pérez wrote:
>We need to tell in the caller, as some errors are expected in a normal
>workflow.  In particular, parent drivers in recent kernels with
>VHOST_BACKEND_F_IOTLB_ASID may not support vring groups.  In that case,
>-ENOTSUP is returned.

So, should we also avoid the error_report if we expect a failure?

Thanks,
Stefano

>
>This is the case of vp_vdpa in Linux 6.2.
>
>Next patches in this series will use that information to know if it must
>abort or not.
>
>Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
>---
> net/vhost-vdpa.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
>diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
>index 99904a0da7..4397c0d4b3 100644
>--- a/net/vhost-vdpa.c
>+++ b/net/vhost-vdpa.c
>@@ -361,6 +361,14 @@ static NetClientInfo net_vhost_vdpa_info = {
>         .check_peer_type = vhost_vdpa_check_peer_type,
> };
>
>+/**
>+ * Get vring virtqueue group
>+ *
>+ * @device_fd  vdpa device fd
>+ * @vq_index   Virtqueue index
>+ *
>+ * Return -errno in case of error, or vq group if success.
>+ */
> static int64_t vhost_vdpa_get_vring_group(int device_fd, unsigned vq_index)
> {
>     struct vhost_vring_state state = {
>@@ -369,6 +377,7 @@ static int64_t vhost_vdpa_get_vring_group(int device_fd, unsigned vq_index)
>     int r = ioctl(device_fd, VHOST_VDPA_GET_VRING_GROUP, &state);
>
>     if (unlikely(r < 0)) {
>+        r = -errno;
>         error_report("Cannot get VQ %u group: %s", vq_index,
>                      g_strerror(errno));
>         return r;
>-- 
>2.31.1
>

On Wed, Mar 22, 2023 at 3:26 PM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> On Fri, Mar 17, 2023 at 03:55:40PM +0100, Eugenio Pérez wrote:
> >We need to tell in the caller, as some errors are expected in a normal
> >workflow.  In particular, parent drivers in recent kernels with
> >VHOST_BACKEND_F_IOTLB_ASID may not support vring groups.  In that case,
> >-ENOTSUP is returned.
>
> So, should we also avoid the error_report if we expect a failure?
>

It's actually replaced by error_setg in next patches, but I think it
is worth commenting on the patch message for sure.

Thanks!

On Wed, Mar 22, 2023 at 06:38:21PM +0100, Eugenio Perez Martin wrote:
>On Wed, Mar 22, 2023 at 3:26 PM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> On Fri, Mar 17, 2023 at 03:55:40PM +0100, Eugenio Pérez wrote:
>> >We need to tell in the caller, as some errors are expected in a normal
>> >workflow.  In particular, parent drivers in recent kernels with
>> >VHOST_BACKEND_F_IOTLB_ASID may not support vring groups.  In that case,
>> >-ENOTSUP is returned.
>>
>> So, should we also avoid the error_report if we expect a failure?
>>
>
>It's actually replaced by error_setg in next patches, but I think it
>is worth commenting on the patch message for sure.

Okay, I see now :-)

Thanks,
Stefano

>
>Thanks!
>