From: Zhenzhong Duan <zhenzhong.duan@intel.com>

When iommufd_cdev_ram_block_discard_disable() fails for whatever reason,
errp should be set or else SIGSEV is triggered in vfio_realize() when
error_prepend() is called.

By this chance, use the same error message for both legacy and iommufd
backend.

Fixes: 5ee3dc7af785 ("vfio/iommufd: Implement the iommufd backend")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20250116102307.260849-1-zhenzhong.duan@intel.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
---
 hw/vfio/iommufd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
index 3490a8f1eb8877c6f662d9676c82888d8713343a..df61edffc084360d9f332ae1d122518c0ecbb955 100644
--- a/hw/vfio/iommufd.c
+++ b/hw/vfio/iommufd.c
@@ -515,8 +515,8 @@ static bool iommufd_cdev_attach(const char *name, VFIODevice *vbasedev,
         } else {
             ret = iommufd_cdev_ram_block_discard_disable(true);
             if (ret) {
-                error_setg(errp,
-                              "Cannot set discarding of RAM broken (%d)", ret);
+                error_setg_errno(errp, -ret,
+                                 "Cannot set discarding of RAM broken");
                 goto err_discard_disable;
             }
             goto found_container;
@@ -544,6 +544,7 @@ static bool iommufd_cdev_attach(const char *name, VFIODevice *vbasedev,
 
     ret = iommufd_cdev_ram_block_discard_disable(true);
     if (ret) {
+        error_setg_errno(errp, -ret, "Cannot set discarding of RAM broken");
         goto err_discard_disable;
     }
 
-- 
2.48.1

11.02.2025 17:33, Cédric Le Goater wrote:
> From: Zhenzhong Duan <zhenzhong.duan@intel.com>
> 
> When iommufd_cdev_ram_block_discard_disable() fails for whatever reason,
> errp should be set or else SIGSEV is triggered in vfio_realize() when
> error_prepend() is called.
> 
> By this chance, use the same error message for both legacy and iommufd
> backend.
> 
> Fixes: 5ee3dc7af785 ("vfio/iommufd: Implement the iommufd backend")
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Link: https://lore.kernel.org/r/20250116102307.260849-1-zhenzhong.duan@intel.com
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> ---
>   hw/vfio/iommufd.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)

This seems to be a qemu-stable material (for 9.2).
Please let me know if it is not.

Thanks,

/mjt

On 2/12/25 20:12, Michael Tokarev wrote:
> 11.02.2025 17:33, Cédric Le Goater wrote:
>> From: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>
>> When iommufd_cdev_ram_block_discard_disable() fails for whatever reason,
>> errp should be set or else SIGSEV is triggered in vfio_realize() when
>> error_prepend() is called.
>>
>> By this chance, use the same error message for both legacy and iommufd
>> backend.
>>
>> Fixes: 5ee3dc7af785 ("vfio/iommufd: Implement the iommufd backend")
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
>> Link: https://lore.kernel.org/r/20250116102307.260849-1-zhenzhong.duan@intel.com
>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>> ---
>>   hw/vfio/iommufd.c | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> This seems to be a qemu-stable material (for 9.2).
> Please let me know if it is not.

For 9.0 and above. It applies cleanly.

Thanks,

C.

13.02.2025 09:32, Cédric Le Goater wrote:
..
>> This seems to be a qemu-stable material (for 9.2).
>> Please let me know if it is not.
> 
> For 9.0 and above. It applies cleanly.

Yup, - I thought it wont be clear.

9.0 & 9.1 are end-of-line at this point, only 9.2 is relevant now.
Also 7.2 and 8.2 are sort of "LTS" (not for this change though).

/mjt

On 2/13/25 07:42, Michael Tokarev wrote:
> 13.02.2025 09:32, Cédric Le Goater wrote:
> ..
>>> This seems to be a qemu-stable material (for 9.2).
>>> Please let me know if it is not.
>>
>> For 9.0 and above. It applies cleanly.
> 
> Yup, - I thought it wont be clear.
> 
> 9.0 & 9.1 are end-of-line at this point, only 9.2 is relevant now.

ok. I didn't know or missed the information.

> Also 7.2 and 8.2 are sort of "LTS" (not for this change though).
> 
> /mjt
  
Is there a stable planning page on the wiki or equivalent else where ?


Thanks,

C.

On 13.02.2025 11:48, Cédric Le Goater wrote:
..
>> 9.0 & 9.1 are end-of-line at this point, only 9.2 is relevant now.
> 
> ok. I didn't know or missed the information.
> 
> Is there a stable planning page on the wiki or equivalent else where ?

I don't think so, no.

The general rule is that I try to keep previous series alive until
the first point release of the next series.  Since 9.2.1 is out,
previous 9.1.x is end-of-life.  Before, the previous stable series
were kept up until the next main release.  Additional to that, 7.2
is an experiment, which is also used on current debian stable, and
also 8.2.

https://wiki.qemu.org/Planning/9.0 etc shows when the series is
end-of-line too.

Thanks,

/mjt