[PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device

[PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device

[Greg Kroah-Hartman]

The vgem driver does not need to create a platform device, as there is
no real platform resources associated it,  it only did so because it was
simple to do that in order to get a device to use for resource
management of drm resources.  Change the driver to use the faux device
instead as this is NOT a real platform device.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v4: - api tweaked due to parent pointer added to faux_device create
      function.
 v3: new patch in the series.  For an example of the api working, does
     not have to be merged at this time, but I can take it if the
     maintainers give an ack.
 drivers/gpu/drm/vgem/vgem_drv.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2752ab4f1c97..260c64733972 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -32,7 +32,7 @@
 
 #include <linux/dma-buf.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/shmem_fs.h>
 #include <linux/vmalloc.h>
 
@@ -52,7 +52,7 @@
 
 static struct vgem_device {
 	struct drm_device drm;
-	struct platform_device *platform;
+	struct faux_device *faux_dev;
 } *vgem_device;
 
 static int vgem_open(struct drm_device *dev, struct drm_file *file)
@@ -127,27 +127,27 @@ static const struct drm_driver vgem_driver = {
 static int __init vgem_init(void)
 {
 	int ret;
-	struct platform_device *pdev;
+	struct faux_device *fdev;
 
-	pdev = platform_device_register_simple("vgem", -1, NULL, 0);
-	if (IS_ERR(pdev))
-		return PTR_ERR(pdev);
+	fdev = faux_device_create("vgem", NULL, NULL);
+	if (!fdev)
+		return -ENODEV;
 
-	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
+	if (!devres_open_group(&fdev->dev, NULL, GFP_KERNEL)) {
 		ret = -ENOMEM;
 		goto out_unregister;
 	}
 
-	dma_coerce_mask_and_coherent(&pdev->dev,
+	dma_coerce_mask_and_coherent(&fdev->dev,
 				     DMA_BIT_MASK(64));
 
-	vgem_device = devm_drm_dev_alloc(&pdev->dev, &vgem_driver,
+	vgem_device = devm_drm_dev_alloc(&fdev->dev, &vgem_driver,
 					 struct vgem_device, drm);
 	if (IS_ERR(vgem_device)) {
 		ret = PTR_ERR(vgem_device);
 		goto out_devres;
 	}
-	vgem_device->platform = pdev;
+	vgem_device->faux_dev = fdev;
 
 	/* Final step: expose the device/driver to userspace */
 	ret = drm_dev_register(&vgem_device->drm, 0);
@@ -157,19 +157,19 @@ static int __init vgem_init(void)
 	return 0;
 
 out_devres:
-	devres_release_group(&pdev->dev, NULL);
+	devres_release_group(&fdev->dev, NULL);
 out_unregister:
-	platform_device_unregister(pdev);
+	faux_device_destroy(fdev);
 	return ret;
 }
 
 static void __exit vgem_exit(void)
 {
-	struct platform_device *pdev = vgem_device->platform;
+	struct faux_device *fdev = vgem_device->faux_dev;
 
 	drm_dev_unregister(&vgem_device->drm);
-	devres_release_group(&pdev->dev, NULL);
-	platform_device_unregister(pdev);
+	devres_release_group(&fdev->dev, NULL);
+	faux_device_destroy(fdev);
 }
 
 module_init(vgem_init);
-- 
2.48.1

Re: [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device

[Thomas Zimmermann]

Hi

Am 10.02.25 um 13:30 schrieb Greg Kroah-Hartman:
> The vgem driver does not need to create a platform device, as there is
> no real platform resources associated it,  it only did so because it was
> simple to do that in order to get a device to use for resource
> management of drm resources.  Change the driver to use the faux device
> instead as this is NOT a real platform device.
>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

Should this patch be merged through DRM trees?

Best regards
Thomas

> ---
> v4: - api tweaked due to parent pointer added to faux_device create
>        function.
>   v3: new patch in the series.  For an example of the api working, does
>       not have to be merged at this time, but I can take it if the
>       maintainers give an ack.
>   drivers/gpu/drm/vgem/vgem_drv.c | 30 +++++++++++++++---------------
>   1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2752ab4f1c97..260c64733972 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -32,7 +32,7 @@
>   
>   #include <linux/dma-buf.h>
>   #include <linux/module.h>
> -#include <linux/platform_device.h>
> +#include <linux/device/faux.h>
>   #include <linux/shmem_fs.h>
>   #include <linux/vmalloc.h>
>   
> @@ -52,7 +52,7 @@
>   
>   static struct vgem_device {
>   	struct drm_device drm;
> -	struct platform_device *platform;
> +	struct faux_device *faux_dev;
>   } *vgem_device;
>   
>   static int vgem_open(struct drm_device *dev, struct drm_file *file)
> @@ -127,27 +127,27 @@ static const struct drm_driver vgem_driver = {
>   static int __init vgem_init(void)
>   {
>   	int ret;
> -	struct platform_device *pdev;
> +	struct faux_device *fdev;
>   
> -	pdev = platform_device_register_simple("vgem", -1, NULL, 0);
> -	if (IS_ERR(pdev))
> -		return PTR_ERR(pdev);
> +	fdev = faux_device_create("vgem", NULL, NULL);
> +	if (!fdev)
> +		return -ENODEV;
>   
> -	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
> +	if (!devres_open_group(&fdev->dev, NULL, GFP_KERNEL)) {
>   		ret = -ENOMEM;
>   		goto out_unregister;
>   	}
>   
> -	dma_coerce_mask_and_coherent(&pdev->dev,
> +	dma_coerce_mask_and_coherent(&fdev->dev,
>   				     DMA_BIT_MASK(64));
>   
> -	vgem_device = devm_drm_dev_alloc(&pdev->dev, &vgem_driver,
> +	vgem_device = devm_drm_dev_alloc(&fdev->dev, &vgem_driver,
>   					 struct vgem_device, drm);
>   	if (IS_ERR(vgem_device)) {
>   		ret = PTR_ERR(vgem_device);
>   		goto out_devres;
>   	}
> -	vgem_device->platform = pdev;
> +	vgem_device->faux_dev = fdev;
>   
>   	/* Final step: expose the device/driver to userspace */
>   	ret = drm_dev_register(&vgem_device->drm, 0);
> @@ -157,19 +157,19 @@ static int __init vgem_init(void)
>   	return 0;
>   
>   out_devres:
> -	devres_release_group(&pdev->dev, NULL);
> +	devres_release_group(&fdev->dev, NULL);
>   out_unregister:
> -	platform_device_unregister(pdev);
> +	faux_device_destroy(fdev);
>   	return ret;
>   }
>   
>   static void __exit vgem_exit(void)
>   {
> -	struct platform_device *pdev = vgem_device->platform;
> +	struct faux_device *fdev = vgem_device->faux_dev;
>   
>   	drm_dev_unregister(&vgem_device->drm);
> -	devres_release_group(&pdev->dev, NULL);
> -	platform_device_unregister(pdev);
> +	devres_release_group(&fdev->dev, NULL);
> +	faux_device_destroy(fdev);
>   }
>   
>   module_init(vgem_init);

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device

[Thomas Zimmermann]

Am 25.02.25 um 12:38 schrieb Thomas Zimmermann:
> Hi
>
> Am 10.02.25 um 13:30 schrieb Greg Kroah-Hartman:
>> The vgem driver does not need to create a platform device, as there is
>> no real platform resources associated it,  it only did so because it was
>> simple to do that in order to get a device to use for resource
>> management of drm resources.  Change the driver to use the faux device
>> instead as this is NOT a real platform device.
>>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: David Airlie <airlied@gmail.com>
>> Cc: Simona Vetter <simona@ffwll.ch>
>> Cc: dri-devel@lists.freedesktop.org
>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Should this patch be merged through DRM trees?

Louis mentioned that the vkms patch will goes through DRM. If no one 
objects, I'll merge this patch there as well.

Best regards
Thomas

>
> Best regards
> Thomas
>
>> ---
>> v4: - api tweaked due to parent pointer added to faux_device create
>>        function.
>>   v3: new patch in the series.  For an example of the api working, does
>>       not have to be merged at this time, but I can take it if the
>>       maintainers give an ack.
>>   drivers/gpu/drm/vgem/vgem_drv.c | 30 +++++++++++++++---------------
>>   1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
>> b/drivers/gpu/drm/vgem/vgem_drv.c
>> index 2752ab4f1c97..260c64733972 100644
>> --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> @@ -32,7 +32,7 @@
>>     #include <linux/dma-buf.h>
>>   #include <linux/module.h>
>> -#include <linux/platform_device.h>
>> +#include <linux/device/faux.h>
>>   #include <linux/shmem_fs.h>
>>   #include <linux/vmalloc.h>
>>   @@ -52,7 +52,7 @@
>>     static struct vgem_device {
>>       struct drm_device drm;
>> -    struct platform_device *platform;
>> +    struct faux_device *faux_dev;
>>   } *vgem_device;
>>     static int vgem_open(struct drm_device *dev, struct drm_file *file)
>> @@ -127,27 +127,27 @@ static const struct drm_driver vgem_driver = {
>>   static int __init vgem_init(void)
>>   {
>>       int ret;
>> -    struct platform_device *pdev;
>> +    struct faux_device *fdev;
>>   -    pdev = platform_device_register_simple("vgem", -1, NULL, 0);
>> -    if (IS_ERR(pdev))
>> -        return PTR_ERR(pdev);
>> +    fdev = faux_device_create("vgem", NULL, NULL);
>> +    if (!fdev)
>> +        return -ENODEV;
>>   -    if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
>> +    if (!devres_open_group(&fdev->dev, NULL, GFP_KERNEL)) {
>>           ret = -ENOMEM;
>>           goto out_unregister;
>>       }
>>   -    dma_coerce_mask_and_coherent(&pdev->dev,
>> +    dma_coerce_mask_and_coherent(&fdev->dev,
>>                        DMA_BIT_MASK(64));
>>   -    vgem_device = devm_drm_dev_alloc(&pdev->dev, &vgem_driver,
>> +    vgem_device = devm_drm_dev_alloc(&fdev->dev, &vgem_driver,
>>                        struct vgem_device, drm);
>>       if (IS_ERR(vgem_device)) {
>>           ret = PTR_ERR(vgem_device);
>>           goto out_devres;
>>       }
>> -    vgem_device->platform = pdev;
>> +    vgem_device->faux_dev = fdev;
>>         /* Final step: expose the device/driver to userspace */
>>       ret = drm_dev_register(&vgem_device->drm, 0);
>> @@ -157,19 +157,19 @@ static int __init vgem_init(void)
>>       return 0;
>>     out_devres:
>> -    devres_release_group(&pdev->dev, NULL);
>> +    devres_release_group(&fdev->dev, NULL);
>>   out_unregister:
>> -    platform_device_unregister(pdev);
>> +    faux_device_destroy(fdev);
>>       return ret;
>>   }
>>     static void __exit vgem_exit(void)
>>   {
>> -    struct platform_device *pdev = vgem_device->platform;
>> +    struct faux_device *fdev = vgem_device->faux_dev;
>>         drm_dev_unregister(&vgem_device->drm);
>> -    devres_release_group(&pdev->dev, NULL);
>> -    platform_device_unregister(pdev);
>> +    devres_release_group(&fdev->dev, NULL);
>> +    faux_device_destroy(fdev);
>>   }
>>     module_init(vgem_init);
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[PATCH v4 9/9] drm/vkms: convert to use faux_device

[Greg Kroah-Hartman]

The vkms driver does not need to create a platform device, as there is
no real platform resources associated it,  it only did so because it was
simple to do that in order to get a device to use for resource
management of drm resources.  Change the driver to use the faux device
instead as this is NOT a real platform device.

Cc: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Melissa Wen <melissa.srw@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v4: - api tweaked due to parent pointer added to faux_device create
      function.
    - fixed space I removed in the .h file
 v3: new patch in the series.  For an example of the api working, does
     not have to be merged at this time, but I can take it if the
     maintainers give an ack.

 drivers/gpu/drm/vkms/vkms_drv.c | 28 ++++++++++++++--------------
 drivers/gpu/drm/vkms/vkms_drv.h |  4 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index e0409aba9349..b3fa0e7c7751 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -10,7 +10,7 @@
  */
 
 #include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/device/faux.h>
 #include <linux/dma-mapping.h>
 
 #include <drm/clients/drm_client_setup.h>
@@ -177,25 +177,25 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
 static int vkms_create(struct vkms_config *config)
 {
 	int ret;
-	struct platform_device *pdev;
+	struct faux_device *fdev;
 	struct vkms_device *vkms_device;
 
-	pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
-	if (IS_ERR(pdev))
-		return PTR_ERR(pdev);
+	fdev = faux_device_create(DRIVER_NAME, NULL, NULL);
+	if (!fdev)
+		return -ENODEV;
 
-	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
+	if (!devres_open_group(&fdev->dev, NULL, GFP_KERNEL)) {
 		ret = -ENOMEM;
 		goto out_unregister;
 	}
 
-	vkms_device = devm_drm_dev_alloc(&pdev->dev, &vkms_driver,
+	vkms_device = devm_drm_dev_alloc(&fdev->dev, &vkms_driver,
 					 struct vkms_device, drm);
 	if (IS_ERR(vkms_device)) {
 		ret = PTR_ERR(vkms_device);
 		goto out_devres;
 	}
-	vkms_device->platform = pdev;
+	vkms_device->faux_dev = fdev;
 	vkms_device->config = config;
 	config->dev = vkms_device;
 
@@ -229,9 +229,9 @@ static int vkms_create(struct vkms_config *config)
 	return 0;
 
 out_devres:
-	devres_release_group(&pdev->dev, NULL);
+	devres_release_group(&fdev->dev, NULL);
 out_unregister:
-	platform_device_unregister(pdev);
+	faux_device_destroy(fdev);
 	return ret;
 }
 
@@ -259,19 +259,19 @@ static int __init vkms_init(void)
 
 static void vkms_destroy(struct vkms_config *config)
 {
-	struct platform_device *pdev;
+	struct faux_device *fdev;
 
 	if (!config->dev) {
 		DRM_INFO("vkms_device is NULL.\n");
 		return;
 	}
 
-	pdev = config->dev->platform;
+	fdev = config->dev->faux_dev;
 
 	drm_dev_unregister(&config->dev->drm);
 	drm_atomic_helper_shutdown(&config->dev->drm);
-	devres_release_group(&pdev->dev, NULL);
-	platform_device_unregister(pdev);
+	devres_release_group(&fdev->dev, NULL);
+	faux_device_destroy(fdev);
 
 	config->dev = NULL;
 }
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 00541eff3d1b..f56af53856f7 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -209,13 +209,13 @@ struct vkms_config {
  * struct vkms_device - Description of a VKMS device
  *
  * @drm - Base device in DRM
- * @platform - Associated platform device
+ * @faux_dev - Associated faux device
  * @output - Configuration and sub-components of the VKMS device
  * @config: Configuration used in this VKMS device
  */
 struct vkms_device {
 	struct drm_device drm;
-	struct platform_device *platform;
+	struct faux_device *faux_dev;
 	struct vkms_output output;
 	const struct vkms_config *config;
 };
-- 
2.48.1

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Louis Chauvet]

On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> The vkms driver does not need to create a platform device, as there is
> no real platform resources associated it,  it only did so because it was
> simple to do that in order to get a device to use for resource
> management of drm resources.  Change the driver to use the faux device
> instead as this is NOT a real platform device.
> 
> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Melissa Wen <melissa.srw@gmail.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>

Thanks for the modification, it seems to work.

Louis chauvet

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Greg Kroah-Hartman]

On Mon, Feb 10, 2025 at 03:37:42PM +0100, Louis Chauvet wrote:
> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > The vkms driver does not need to create a platform device, as there is
> > no real platform resources associated it,  it only did so because it was
> > simple to do that in order to get a device to use for resource
> > management of drm resources.  Change the driver to use the faux device
> > instead as this is NOT a real platform device.
> > 
> > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > Cc: Simona Vetter <simona@ffwll.ch>
> > Cc: Melissa Wen <melissa.srw@gmail.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: David Airlie <airlied@gmail.com>
> > Cc: dri-devel@lists.freedesktop.org
> > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> 
> Thanks for the modification, it seems to work.

Great, thanks for testing!

greg k-h

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Thomas Zimmermann]

Hi

Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>> The vkms driver does not need to create a platform device, as there is
>> no real platform resources associated it,  it only did so because it was
>> simple to do that in order to get a device to use for resource
>> management of drm resources.  Change the driver to use the faux device
>> instead as this is NOT a real platform device.
>>
>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>> Cc: Simona Vetter <simona@ffwll.ch>
>> Cc: Melissa Wen <melissa.srw@gmail.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: David Airlie <airlied@gmail.com>
>> Cc: dri-devel@lists.freedesktop.org
>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>
> Thanks for the modification, it seems to work.

Should this patch be merged through DRM trees? drm-misc-next is at 
v6.14-rc4 and has struct faux_device.

Best regards
Thomas



>
> Louis chauvet
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Louis Chauvet]

Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> Hi
> 
> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>> The vkms driver does not need to create a platform device, as there is
>>> no real platform resources associated it,  it only did so because it was
>>> simple to do that in order to get a device to use for resource
>>> management of drm resources.  Change the driver to use the faux device
>>> instead as this is NOT a real platform device.
>>>
>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>> Cc: Simona Vetter <simona@ffwll.ch>
>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>> Cc: Maxime Ripard <mripard@kernel.org>
>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>> Cc: David Airlie <airlied@gmail.com>
>>> Cc: dri-devel@lists.freedesktop.org
>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>
>> Thanks for the modification, it seems to work.
> 
> Should this patch be merged through DRM trees? drm-misc-next is at
> v6.14-rc4 and has struct faux_device.

Hi,

I was not aware the faux-device was merged, as it is a new feature, I 
expected it to reach drm-misc-next on 6.15-rc1.

I plan to merge [1] today/tomorrow (well tested with platform_device), 
and then I will submit an updated version of this patch (only trivial 
conflicts, but never tested with multiple VKMS devices).

[1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/

Thanks,
Louis Chauvet

> Best regards
> Thomas
> 
> 
> 
>>
>> Louis chauvet
>>
> 

-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Greg Kroah-Hartman]

On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> 
> 
> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > Hi
> > 
> > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > The vkms driver does not need to create a platform device, as there is
> > > > no real platform resources associated it,  it only did so because it was
> > > > simple to do that in order to get a device to use for resource
> > > > management of drm resources.  Change the driver to use the faux device
> > > > instead as this is NOT a real platform device.
> > > > 
> > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > Cc: David Airlie <airlied@gmail.com>
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > 
> > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > 
> > > Thanks for the modification, it seems to work.
> > 
> > Should this patch be merged through DRM trees? drm-misc-next is at
> > v6.14-rc4 and has struct faux_device.
> 
> Hi,
> 
> I was not aware the faux-device was merged, as it is a new feature, I
> expected it to reach drm-misc-next on 6.15-rc1.

I added it to Linus's tree just so that DRM could get these changes into
their tree now :)

> I plan to merge [1] today/tomorrow (well tested with platform_device), and
> then I will submit an updated version of this patch (only trivial conflicts,
> but never tested with multiple VKMS devices).
> 
> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/

Great, thanks!

greg k-h

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[José Expósito]

Hi everyone,

> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > 
> > 
> > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > Hi
> > > 
> > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > The vkms driver does not need to create a platform device, as there is
> > > > > no real platform resources associated it,  it only did so because it was
> > > > > simple to do that in order to get a device to use for resource
> > > > > management of drm resources.  Change the driver to use the faux device
> > > > > instead as this is NOT a real platform device.
> > > > > 
> > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > 
> > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > 
> > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > 
> > > > Thanks for the modification, it seems to work.
> > > 
> > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > v6.14-rc4 and has struct faux_device.
> > 
> > Hi,
> > 
> > I was not aware the faux-device was merged, as it is a new feature, I
> > expected it to reach drm-misc-next on 6.15-rc1.
> 
> I added it to Linus's tree just so that DRM could get these changes into
> their tree now :)
> 
> > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > then I will submit an updated version of this patch (only trivial conflicts,
> > but never tested with multiple VKMS devices).
> > 
> > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> 
> Great, thanks!
> 
> greg k-h

Testing this patch again as part of some IGT tests I'm working on,
I noticed that, applying this patch on top of the latest drm-misc-next
triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
drm_gem_get_pages():

    if (WARN_ON(!obj->filp))
            return ERR_PTR(-EINVAL);

To double check that the cause were not my local changes, I checked
out commit 2d4d775d11d3 ("drm: pl111: fix inconsistent indenting
warning"), which doesn't contain any vkms config changes, applied this
patch and the result is the same.

Louis, do you also see this warning?

For reference, the log is at the end of this email.
Jose

---

[  110.126952] [drm] Initialized vkms 1.0.0 for vkms on minor 1
[  110.129193] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
[  110.326759] ------------[ cut here ]------------
[  110.326769] WARNING: CPU: 5 PID: 1106 at drivers/gpu/drm/drm_gem.c:571 drm_gem_get_pages+0x5e9/0x780
[  110.326795] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc e1000 parport i2c_piix4 pcspkr i2c_smbus joydev loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci zram vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
[  110.326892] CPU: 5 UID: 42 PID: 1106 Comm: KMS thread Not tainted 6.14.0-rc4+ #2
[  110.326898] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[  110.326902] RIP: 0010:drm_gem_get_pages+0x5e9/0x780
[  110.326909] Code: 8d bd 78 fe ff ff e8 76 ca 8c fe 48 8d bd 78 fe ff ff e8 ea d9 8a fe e8 75 1a 17 01 e9 4b ff ff ff 48 8d 58 ff e9 6a fe ff ff <0f> 0b 49 c7 c7 ea ff ff ff e9 40 ff ff ff 0f 0b e9 0f fb ff ff 4c
[  110.326914] RSP: 0018:ffffc9000572f550 EFLAGS: 00010246
[  110.326919] RAX: 1ffff11024531402 RBX: ffff88812298a000 RCX: 0000000000000000
[  110.326923] RDX: dffffc0000000000 RSI: ffff8881125d54c8 RDI: ffff88812298a010
[  110.326927] RBP: ffffc9000572f750 R08: 8000000000000063 R09: fffff52000ae5ef0
[  110.326929] R10: ffffc9000572f787 R11: ffff888104638528 R12: 0000000000000000
[  110.326932] R13: ffff88812298a168 R14: ffff88812298a0e8 R15: ffff88812298a190
[  110.326936] FS:  00007f3cf4e536c0(0000) GS:ffff8883af080000(0000) knlGS:0000000000000000
[  110.326940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  110.326944] CR2: 00007f3cd40337f8 CR3: 00000001394e4000 CR4: 00000000000006f0
[  110.326951] Call Trace:
[  110.326954]  <TASK>
[  110.326957]  ? show_regs.cold+0x19/0x1e
[  110.326965]  ? __warn.cold+0xbd/0x17f
[  110.326970]  ? drm_gem_get_pages+0x5e9/0x780
[  110.326975]  ? report_bug+0x20b/0x2d0
[  110.326982]  ? handle_bug+0x60/0xa0
[  110.326988]  ? exc_invalid_op+0x1c/0x50
[  110.326993]  ? asm_exc_invalid_op+0x1f/0x30
[  110.327000]  ? drm_gem_get_pages+0x5e9/0x780
[  110.327005]  ? kasan_save_stack+0x4d/0x60
[  110.327011]  ? kasan_save_stack+0x3d/0x60
[  110.327016]  ? kasan_save_track+0x1c/0x70
[  110.327020]  ? kasan_save_alloc_info+0x3b/0x50
[  110.327025]  ? __pfx_drm_gem_get_pages+0x10/0x10
[  110.327029]  ? drm_atomic_helper_commit+0x7c/0x290
[  110.327037]  ? dma_resv_get_singleton+0x99/0x2b0
[  110.327043]  drm_gem_shmem_get_pages+0x69/0x1f0
[  110.327048]  drm_gem_shmem_vmap+0x1f8/0x670
[  110.327054]  drm_gem_shmem_object_vmap+0xd/0x20
[  110.327058]  drm_gem_vmap+0x70/0xd0
[  110.327063]  drm_gem_vmap_unlocked+0x4f/0xa0
[  110.327067]  drm_gem_fb_vmap+0xaf/0x3c0
[  110.327073]  vkms_prepare_fb+0x6e/0x80 [vkms]
[  110.327081]  drm_atomic_helper_prepare_planes+0x1a5/0xba0
[  110.327088]  drm_atomic_helper_commit+0x128/0x290
[  110.327092]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
[  110.327097]  drm_atomic_commit+0x203/0x2d0
[  110.327101]  ? _raw_spin_lock_irqsave+0x97/0xf0
[  110.327106]  ? __pfx_drm_atomic_commit+0x10/0x10
[  110.327110]  ? __pfx___drm_printfn_info+0x10/0x10
[  110.327116]  ? drm_event_reserve_init+0x1cd/0x260
[  110.327123]  drm_mode_atomic_ioctl+0x1d2b/0x2d30
[  110.327129]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[  110.327134]  ? __kasan_check_write+0x18/0x20
[  110.327140]  drm_ioctl_kernel+0x177/0x2f0
[  110.327145]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[  110.327149]  ? __pfx_drm_ioctl_kernel+0x10/0x10
[  110.327155]  ? __kasan_check_write+0x18/0x20
[  110.327160]  drm_ioctl+0x557/0xc90
[  110.327165]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[  110.327170]  ? __pfx_drm_ioctl+0x10/0x10
[  110.327176]  ? selinux_file_ioctl+0x106/0x250
[  110.327181]  ? fdget+0x2ca/0x3d0
[  110.327185]  ? selinux_file_ioctl+0x106/0x250
[  110.327191]  __x64_sys_ioctl+0x13c/0x1a0
[  110.327198]  x64_sys_call+0xf3b/0x1d70
[  110.327202]  do_syscall_64+0x82/0x160
[  110.327208]  ? irqentry_exit+0x3f/0x50
[  110.327213]  ? exc_page_fault+0x94/0x110
[  110.327218]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  110.327223] RIP: 0033:0x7f3d100fda6d
[  110.327234] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[  110.327238] RSP: 002b:00007f3cf4e519b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  110.327244] RAX: ffffffffffffffda RBX: 00007f3cd402a440 RCX: 00007f3d100fda6d
[  110.327247] RDX: 00007f3cf4e51a50 RSI: 00000000c03864bc RDI: 0000000000000035
[  110.327250] RBP: 00007f3cf4e51a00 R08: 00000000000000d0 R09: 0000000000000001
[  110.327254] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f3cf4e51a50
[  110.327257] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007f3cd4029f20
[  110.327262]  </TASK>
[  110.327264] ---[ end trace 0000000000000000 ]---

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[José Expósito]

On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> Hi everyone,
> 
> > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > 
> > > 
> > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > Hi
> > > > 
> > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > simple to do that in order to get a device to use for resource
> > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > instead as this is NOT a real platform device.
> > > > > > 
> > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > 
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > 
> > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > 
> > > > > Thanks for the modification, it seems to work.
> > > > 
> > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > v6.14-rc4 and has struct faux_device.
> > > 
> > > Hi,
> > > 
> > > I was not aware the faux-device was merged, as it is a new feature, I
> > > expected it to reach drm-misc-next on 6.15-rc1.
> > 
> > I added it to Linus's tree just so that DRM could get these changes into
> > their tree now :)
> > 
> > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > then I will submit an updated version of this patch (only trivial conflicts,
> > > but never tested with multiple VKMS devices).
> > > 
> > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > 
> > Great, thanks!
> > 
> > greg k-h
> 
> Testing this patch again as part of some IGT tests I'm working on,
> I noticed that, applying this patch on top of the latest drm-misc-next
> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> drm_gem_get_pages():
> 
>     if (WARN_ON(!obj->filp))
>             return ERR_PTR(-EINVAL);

I forgot to mention that this warning is triggered just by `sudo modprobe vkms`.

Sorry for the additional email.
Jose

> To double check that the cause were not my local changes, I checked
> out commit 2d4d775d11d3 ("drm: pl111: fix inconsistent indenting
> warning"), which doesn't contain any vkms config changes, applied this
> patch and the result is the same.
> 
> Louis, do you also see this warning?
> 
> For reference, the log is at the end of this email.
> Jose
> 
> ---
> 
> [  110.126952] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> [  110.129193] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> [  110.326759] ------------[ cut here ]------------
> [  110.326769] WARNING: CPU: 5 PID: 1106 at drivers/gpu/drm/drm_gem.c:571 drm_gem_get_pages+0x5e9/0x780
> [  110.326795] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc e1000 parport i2c_piix4 pcspkr i2c_smbus joydev loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci zram vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> [  110.326892] CPU: 5 UID: 42 PID: 1106 Comm: KMS thread Not tainted 6.14.0-rc4+ #2
> [  110.326898] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
> [  110.326902] RIP: 0010:drm_gem_get_pages+0x5e9/0x780
> [  110.326909] Code: 8d bd 78 fe ff ff e8 76 ca 8c fe 48 8d bd 78 fe ff ff e8 ea d9 8a fe e8 75 1a 17 01 e9 4b ff ff ff 48 8d 58 ff e9 6a fe ff ff <0f> 0b 49 c7 c7 ea ff ff ff e9 40 ff ff ff 0f 0b e9 0f fb ff ff 4c
> [  110.326914] RSP: 0018:ffffc9000572f550 EFLAGS: 00010246
> [  110.326919] RAX: 1ffff11024531402 RBX: ffff88812298a000 RCX: 0000000000000000
> [  110.326923] RDX: dffffc0000000000 RSI: ffff8881125d54c8 RDI: ffff88812298a010
> [  110.326927] RBP: ffffc9000572f750 R08: 8000000000000063 R09: fffff52000ae5ef0
> [  110.326929] R10: ffffc9000572f787 R11: ffff888104638528 R12: 0000000000000000
> [  110.326932] R13: ffff88812298a168 R14: ffff88812298a0e8 R15: ffff88812298a190
> [  110.326936] FS:  00007f3cf4e536c0(0000) GS:ffff8883af080000(0000) knlGS:0000000000000000
> [  110.326940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  110.326944] CR2: 00007f3cd40337f8 CR3: 00000001394e4000 CR4: 00000000000006f0
> [  110.326951] Call Trace:
> [  110.326954]  <TASK>
> [  110.326957]  ? show_regs.cold+0x19/0x1e
> [  110.326965]  ? __warn.cold+0xbd/0x17f
> [  110.326970]  ? drm_gem_get_pages+0x5e9/0x780
> [  110.326975]  ? report_bug+0x20b/0x2d0
> [  110.326982]  ? handle_bug+0x60/0xa0
> [  110.326988]  ? exc_invalid_op+0x1c/0x50
> [  110.326993]  ? asm_exc_invalid_op+0x1f/0x30
> [  110.327000]  ? drm_gem_get_pages+0x5e9/0x780
> [  110.327005]  ? kasan_save_stack+0x4d/0x60
> [  110.327011]  ? kasan_save_stack+0x3d/0x60
> [  110.327016]  ? kasan_save_track+0x1c/0x70
> [  110.327020]  ? kasan_save_alloc_info+0x3b/0x50
> [  110.327025]  ? __pfx_drm_gem_get_pages+0x10/0x10
> [  110.327029]  ? drm_atomic_helper_commit+0x7c/0x290
> [  110.327037]  ? dma_resv_get_singleton+0x99/0x2b0
> [  110.327043]  drm_gem_shmem_get_pages+0x69/0x1f0
> [  110.327048]  drm_gem_shmem_vmap+0x1f8/0x670
> [  110.327054]  drm_gem_shmem_object_vmap+0xd/0x20
> [  110.327058]  drm_gem_vmap+0x70/0xd0
> [  110.327063]  drm_gem_vmap_unlocked+0x4f/0xa0
> [  110.327067]  drm_gem_fb_vmap+0xaf/0x3c0
> [  110.327073]  vkms_prepare_fb+0x6e/0x80 [vkms]
> [  110.327081]  drm_atomic_helper_prepare_planes+0x1a5/0xba0
> [  110.327088]  drm_atomic_helper_commit+0x128/0x290
> [  110.327092]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [  110.327097]  drm_atomic_commit+0x203/0x2d0
> [  110.327101]  ? _raw_spin_lock_irqsave+0x97/0xf0
> [  110.327106]  ? __pfx_drm_atomic_commit+0x10/0x10
> [  110.327110]  ? __pfx___drm_printfn_info+0x10/0x10
> [  110.327116]  ? drm_event_reserve_init+0x1cd/0x260
> [  110.327123]  drm_mode_atomic_ioctl+0x1d2b/0x2d30
> [  110.327129]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [  110.327134]  ? __kasan_check_write+0x18/0x20
> [  110.327140]  drm_ioctl_kernel+0x177/0x2f0
> [  110.327145]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [  110.327149]  ? __pfx_drm_ioctl_kernel+0x10/0x10
> [  110.327155]  ? __kasan_check_write+0x18/0x20
> [  110.327160]  drm_ioctl+0x557/0xc90
> [  110.327165]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [  110.327170]  ? __pfx_drm_ioctl+0x10/0x10
> [  110.327176]  ? selinux_file_ioctl+0x106/0x250
> [  110.327181]  ? fdget+0x2ca/0x3d0
> [  110.327185]  ? selinux_file_ioctl+0x106/0x250
> [  110.327191]  __x64_sys_ioctl+0x13c/0x1a0
> [  110.327198]  x64_sys_call+0xf3b/0x1d70
> [  110.327202]  do_syscall_64+0x82/0x160
> [  110.327208]  ? irqentry_exit+0x3f/0x50
> [  110.327213]  ? exc_page_fault+0x94/0x110
> [  110.327218]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [  110.327223] RIP: 0033:0x7f3d100fda6d
> [  110.327234] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> [  110.327238] RSP: 002b:00007f3cf4e519b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [  110.327244] RAX: ffffffffffffffda RBX: 00007f3cd402a440 RCX: 00007f3d100fda6d
> [  110.327247] RDX: 00007f3cf4e51a50 RSI: 00000000c03864bc RDI: 0000000000000035
> [  110.327250] RBP: 00007f3cf4e51a00 R08: 00000000000000d0 R09: 0000000000000001
> [  110.327254] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f3cf4e51a50
> [  110.327257] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007f3cd4029f20
> [  110.327262]  </TASK>
> [  110.327264] ---[ end trace 0000000000000000 ]---

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Greg KH]

On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> Hi everyone,
> 
> > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > 
> > > 
> > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > Hi
> > > > 
> > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > simple to do that in order to get a device to use for resource
> > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > instead as this is NOT a real platform device.
> > > > > > 
> > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > 
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > 
> > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > 
> > > > > Thanks for the modification, it seems to work.
> > > > 
> > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > v6.14-rc4 and has struct faux_device.
> > > 
> > > Hi,
> > > 
> > > I was not aware the faux-device was merged, as it is a new feature, I
> > > expected it to reach drm-misc-next on 6.15-rc1.
> > 
> > I added it to Linus's tree just so that DRM could get these changes into
> > their tree now :)
> > 
> > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > then I will submit an updated version of this patch (only trivial conflicts,
> > > but never tested with multiple VKMS devices).
> > > 
> > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > 
> > Great, thanks!
> > 
> > greg k-h
> 
> Testing this patch again as part of some IGT tests I'm working on,
> I noticed that, applying this patch on top of the latest drm-misc-next
> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> drm_gem_get_pages():
> 
>     if (WARN_ON(!obj->filp))
>             return ERR_PTR(-EINVAL);

I don't see how the faux bus change would have anything to do with a
filp as that's not related as far as I can tell.  But I don't know the
drm layer at all, where does that filp come from?

thanks,

greg k-h

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Simona Vetter]

On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > Hi everyone,
> > 
> > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > 
> > > > 
> > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > Hi
> > > > > 
> > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > > instead as this is NOT a real platform device.
> > > > > > > 
> > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > 
> > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > 
> > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > 
> > > > > > Thanks for the modification, it seems to work.
> > > > > 
> > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > v6.14-rc4 and has struct faux_device.
> > > > 
> > > > Hi,
> > > > 
> > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > 
> > > I added it to Linus's tree just so that DRM could get these changes into
> > > their tree now :)
> > > 
> > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > but never tested with multiple VKMS devices).
> > > > 
> > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > 
> > > Great, thanks!
> > > 
> > > greg k-h
> > 
> > Testing this patch again as part of some IGT tests I'm working on,
> > I noticed that, applying this patch on top of the latest drm-misc-next
> > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > drm_gem_get_pages():
> > 
> >     if (WARN_ON(!obj->filp))
> >             return ERR_PTR(-EINVAL);
> 
> I don't see how the faux bus change would have anything to do with a
> filp as that's not related as far as I can tell.  But I don't know the
> drm layer at all, where does that filp come from?

Yeah that filp is the shmem file that backs gem bo. That's very far away
from anything device/driver related datastrctures. If this is a new
failure due to the aux bux conversion then it would be really surprising.
-Sima

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[José Expósito]

On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > Hi everyone,
> > > 
> > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > > 
> > > > > 
> > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > > Hi
> > > > > > 
> > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > > > instead as this is NOT a real platform device.
> > > > > > > > 
> > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > 
> > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > 
> > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > 
> > > > > > > Thanks for the modification, it seems to work.
> > > > > > 
> > > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > > v6.14-rc4 and has struct faux_device.
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > > 
> > > > I added it to Linus's tree just so that DRM could get these changes into
> > > > their tree now :)
> > > > 
> > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > > but never tested with multiple VKMS devices).
> > > > > 
> > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > > 
> > > > Great, thanks!
> > > > 
> > > > greg k-h
> > > 
> > > Testing this patch again as part of some IGT tests I'm working on,
> > > I noticed that, applying this patch on top of the latest drm-misc-next
> > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > > drm_gem_get_pages():
> > > 
> > >     if (WARN_ON(!obj->filp))
> > >             return ERR_PTR(-EINVAL);
> > 
> > I don't see how the faux bus change would have anything to do with a
> > filp as that's not related as far as I can tell.  But I don't know the
> > drm layer at all, where does that filp come from?
> 
> Yeah that filp is the shmem file that backs gem bo. That's very far away
> from anything device/driver related datastrctures. If this is a new
> failure due to the aux bux conversion then it would be really surprising.

Agreed, I find it surprising, but reverting the patch removes the warning.

It's most likely an issue on my side, but I decided to double check just
in case someone else is also seeing this warning.

Jose

> -Sima
> 
> -- 
> Simona Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Thomas Zimmermann]

Hi

Am 13.03.25 um 18:20 schrieb José Expósito:
> On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
>> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
>>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
>>>> Hi everyone,
>>>>
>>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
>>>>>>
>>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
>>>>>>> Hi
>>>>>>>
>>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>>>>>>>> The vkms driver does not need to create a platform device, as there is
>>>>>>>>> no real platform resources associated it,  it only did so because it was
>>>>>>>>> simple to do that in order to get a device to use for resource
>>>>>>>>> management of drm resources.  Change the driver to use the faux device
>>>>>>>>> instead as this is NOT a real platform device.
>>>>>>>>>
>>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch>
>>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org>
>>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>> Cc: David Airlie <airlied@gmail.com>
>>>>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>
>>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>
>>>>>>>> Thanks for the modification, it seems to work.
>>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at
>>>>>>> v6.14-rc4 and has struct faux_device.
>>>>>> Hi,
>>>>>>
>>>>>> I was not aware the faux-device was merged, as it is a new feature, I
>>>>>> expected it to reach drm-misc-next on 6.15-rc1.
>>>>> I added it to Linus's tree just so that DRM could get these changes into
>>>>> their tree now :)
>>>>>
>>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and
>>>>>> then I will submit an updated version of this patch (only trivial conflicts,
>>>>>> but never tested with multiple VKMS devices).
>>>>>>
>>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>>>>> Great, thanks!
>>>>>
>>>>> greg k-h
>>>> Testing this patch again as part of some IGT tests I'm working on,
>>>> I noticed that, applying this patch on top of the latest drm-misc-next
>>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
>>>> drm_gem_get_pages():
>>>>
>>>>      if (WARN_ON(!obj->filp))
>>>>              return ERR_PTR(-EINVAL);
>>> I don't see how the faux bus change would have anything to do with a
>>> filp as that's not related as far as I can tell.  But I don't know the
>>> drm layer at all, where does that filp come from?
>> Yeah that filp is the shmem file that backs gem bo. That's very far away
>> from anything device/driver related datastrctures. If this is a new
>> failure due to the aux bux conversion then it would be really surprising.
> Agreed, I find it surprising, but reverting the patch removes the warning.
>
> It's most likely an issue on my side, but I decided to double check just
> in case someone else is also seeing this warning.

Any news on this issue?

Best regards
Thomas

>
> Jose
>
>> -Sima
>>
>> -- 
>> Simona Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[José Expósito]

Hi Thomas,

Thanks for the heads up, this issue fall through the cracks.

On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 13.03.25 um 18:20 schrieb José Expósito:
> > On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> > > On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > > > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > > > > 
> > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > > > > Hi
> > > > > > > > 
> > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > > > > > instead as this is NOT a real platform device.
> > > > > > > > > > 
> > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > 
> > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > 
> > > > > > > > > Thanks for the modification, it seems to work.
> > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > > > > v6.14-rc4 and has struct faux_device.
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > > > > I added it to Linus's tree just so that DRM could get these changes into
> > > > > > their tree now :)
> > > > > > 
> > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > > > > but never tested with multiple VKMS devices).
> > > > > > > 
> > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > > > > Great, thanks!
> > > > > > 
> > > > > > greg k-h
> > > > > Testing this patch again as part of some IGT tests I'm working on,
> > > > > I noticed that, applying this patch on top of the latest drm-misc-next
> > > > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > > > > drm_gem_get_pages():
> > > > > 
> > > > >      if (WARN_ON(!obj->filp))
> > > > >              return ERR_PTR(-EINVAL);
> > > > I don't see how the faux bus change would have anything to do with a
> > > > filp as that's not related as far as I can tell.  But I don't know the
> > > > drm layer at all, where does that filp come from?
> > > Yeah that filp is the shmem file that backs gem bo. That's very far away
> > > from anything device/driver related datastrctures. If this is a new
> > > failure due to the aux bux conversion then it would be really surprising.
> > Agreed, I find it surprising, but reverting the patch removes the warning.
> > 
> > It's most likely an issue on my side, but I decided to double check just
> > in case someone else is also seeing this warning.
> 
> Any news on this issue?

I tested again with drm-misc-next. At the moment of writing this, the last
commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
access rules") and I still see a similar warning. The stack trace changed,
but the warning is still present.

I'm going to detail the exact steps I followed. Let's see if someone else is
able to reproduce the issue:

I started by applying the patches from this series that are not already merged:

 - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
 - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
 - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
 - [PATCH v4 9/9] drm/vkms: convert to use faux_device

The last patch has small conflict in vkms_drv.h that I solved like this:

	struct vkms_device {
		struct drm_device drm;
		struct faux_device *faux_dev;
		const struct vkms_config *config;
	};

And in vkms_drv.c:

	static int vkms_create(struct vkms_config *config)
	{
		int ret;
		struct faux_device *fdev;
		struct vkms_device *vkms_device;
		const char *dev_name;

		dev_name = vkms_config_get_device_name(config);
		fdev = faux_device_create(dev_name, NULL, NULL);
		if (!fdev)
			return -ENODEV;

Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
There is nothing special about my Fedora, it is the regular desktop version.

After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
For reference, the warning is at the end of my email.

Am I the only one sawing this warning?

Jose

---

[   69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
[   69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
[   69.520944] ------------[ cut here ]------------
[   69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
[   69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
[   69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary) 
[   69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
[   69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
[   69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
[   69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
[   69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
[   69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
[   69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
[   69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
[   69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
[   69.521168] FS:  00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
[   69.521172] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
[   69.521179] Call Trace:
[   69.521182]  <TASK>
[   69.521185]  ? __pfx_dma_buf_vmap+0x10/0x10
[   69.521193]  ? dma_resv_get_singleton+0x9a/0x2a0
[   69.521197]  drm_gem_shmem_vmap_locked+0xc2/0x5f0
[   69.521208]  ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
[   69.521212]  ? __pfx_ww_mutex_lock+0x10/0x10
[   69.521225]  ? sched_clock_noinstr+0xd/0x20
[   69.521230]  ? local_clock_noinstr+0x13/0xf0
[   69.521233]  drm_gem_shmem_object_vmap+0xd/0x20
[   69.521237]  drm_gem_vmap_locked+0x70/0xf0
[   69.521247]  drm_gem_vmap+0x4c/0xa0
[   69.521250]  drm_gem_fb_vmap+0xb2/0x3b0
[   69.521255]  vkms_prepare_fb+0x6f/0x90 [vkms]
[   69.521264]  ? drm_atomic_helper_setup_commit+0xb7b/0x1320
[   69.521268]  drm_atomic_helper_prepare_planes+0x19f/0xb90
[   69.521272]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
[   69.521276]  drm_atomic_helper_commit+0x126/0x2d0
[   69.521279]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
[   69.521282]  drm_atomic_commit+0x205/0x2d0
[   69.521290]  ? _raw_spin_lock_irqsave+0x97/0xf0
[   69.521295]  ? __pfx_drm_atomic_commit+0x10/0x10
[   69.521299]  ? __pfx___drm_printfn_info+0x10/0x10
[   69.521313]  ? drm_event_reserve_init+0x1cd/0x260
[   69.521318]  drm_mode_atomic_ioctl+0x1c79/0x2d30
[   69.521323]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   69.521326]  ? __kasan_check_write+0x18/0x20
[   69.521339]  drm_ioctl_kernel+0x17b/0x2f0
[   69.521343]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   69.521349]  ? __pfx_drm_ioctl_kernel+0x10/0x10
[   69.521353]  ? __pfx_do_vfs_ioctl+0x10/0x10
[   69.521361]  ? __kasan_check_write+0x18/0x20
[   69.521365]  drm_ioctl+0x51b/0xbd0
[   69.521369]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   69.521373]  ? __pfx_drm_ioctl+0x10/0x10
[   69.521378]  ? selinux_file_ioctl+0xfc/0x260
[   69.521390]  __x64_sys_ioctl+0x143/0x1d0
[   69.521394]  x64_sys_call+0xf4b/0x1d70
[   69.521404]  do_syscall_64+0x82/0x2a0
[   69.521408]  ? __kasan_check_write+0x18/0x20
[   69.521411]  ? do_user_addr_fault+0x491/0xa60
[   69.521420]  ? irqentry_exit+0x3f/0x50
[   69.521423]  ? exc_page_fault+0x8b/0xe0
[   69.521426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   69.521430] RIP: 0033:0x7fbc078fd8ed
[   69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[   69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
[   69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
[   69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
[   69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
[   69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
[   69.521464]  </TASK>
[   69.521466] ---[ end trace 0000000000000000 ]---



> Best regards
> Thomas
> 
> > 
> > Jose
> > 
> > > -Sima
> > > 
> > > -- 
> > > Simona Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> 
> -- 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
> 

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Thomas Zimmermann]

Hi

Am 13.06.25 um 13:55 schrieb José Expósito:
> Hi Thomas,
>
> Thanks for the heads up, this issue fall through the cracks.
>
> On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 13.03.25 um 18:20 schrieb José Expósito:
>>> On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
>>>> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
>>>>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
>>>>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>>>>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>>>>>>>>>> The vkms driver does not need to create a platform device, as there is
>>>>>>>>>>> no real platform resources associated it,  it only did so because it was
>>>>>>>>>>> simple to do that in order to get a device to use for resource
>>>>>>>>>>> management of drm resources.  Change the driver to use the faux device
>>>>>>>>>>> instead as this is NOT a real platform device.
>>>>>>>>>>>
>>>>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>>>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch>
>>>>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>>>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org>
>>>>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>> Cc: David Airlie <airlied@gmail.com>
>>>>>>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>
>>>>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>
>>>>>>>>>> Thanks for the modification, it seems to work.
>>>>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at
>>>>>>>>> v6.14-rc4 and has struct faux_device.
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was not aware the faux-device was merged, as it is a new feature, I
>>>>>>>> expected it to reach drm-misc-next on 6.15-rc1.
>>>>>>> I added it to Linus's tree just so that DRM could get these changes into
>>>>>>> their tree now :)
>>>>>>>
>>>>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and
>>>>>>>> then I will submit an updated version of this patch (only trivial conflicts,
>>>>>>>> but never tested with multiple VKMS devices).
>>>>>>>>
>>>>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>>>>>>> Great, thanks!
>>>>>>>
>>>>>>> greg k-h
>>>>>> Testing this patch again as part of some IGT tests I'm working on,
>>>>>> I noticed that, applying this patch on top of the latest drm-misc-next
>>>>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
>>>>>> drm_gem_get_pages():
>>>>>>
>>>>>>       if (WARN_ON(!obj->filp))
>>>>>>               return ERR_PTR(-EINVAL);
>>>>> I don't see how the faux bus change would have anything to do with a
>>>>> filp as that's not related as far as I can tell.  But I don't know the
>>>>> drm layer at all, where does that filp come from?
>>>> Yeah that filp is the shmem file that backs gem bo. That's very far away
>>>> from anything device/driver related datastrctures. If this is a new
>>>> failure due to the aux bux conversion then it would be really surprising.
>>> Agreed, I find it surprising, but reverting the patch removes the warning.
>>>
>>> It's most likely an issue on my side, but I decided to double check just
>>> in case someone else is also seeing this warning.
>> Any news on this issue?
> I tested again with drm-misc-next. At the moment of writing this, the last
> commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
> access rules") and I still see a similar warning. The stack trace changed,
> but the warning is still present.
>
> I'm going to detail the exact steps I followed. Let's see if someone else is
> able to reproduce the issue:
>
> I started by applying the patches from this series that are not already merged:
>
>   - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
>   - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
>   - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
>   - [PATCH v4 9/9] drm/vkms: convert to use faux_device
>
> The last patch has small conflict in vkms_drv.h that I solved like this:
>
> 	struct vkms_device {
> 		struct drm_device drm;
> 		struct faux_device *faux_dev;
> 		const struct vkms_config *config;
> 	};
>
> And in vkms_drv.c:
>
> 	static int vkms_create(struct vkms_config *config)
> 	{
> 		int ret;
> 		struct faux_device *fdev;
> 		struct vkms_device *vkms_device;
> 		const char *dev_name;
>
> 		dev_name = vkms_config_get_device_name(config);
> 		fdev = faux_device_create(dev_name, NULL, NULL);
> 		if (!fdev)
> 			return -ENODEV;
>
> Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
> There is nothing special about my Fedora, it is the regular desktop version.
>
> After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
> For reference, the warning is at the end of my email.
>
> Am I the only one sawing this warning?
>
> Jose
>
> ---
>
> [   69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> [   69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> [   69.520944] ------------[ cut here ]------------
> [   69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
> [   69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> [   69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
> [   69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> [   69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540

That's dmabuf. could be related to the fact that there's no real DMA 
possible with the faux_device. We now have support for 
dmabuf-without-DMA, sort of. Could you please replace 
DRM_GEM_SHMEM_DRIVER_OPS with the new 
DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual 
hardware-DMA functionality.

[1] 
https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104

Best regards
Thomas


> [   69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
> [   69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
> [   69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
> [   69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
> [   69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
> [   69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
> [   69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
> [   69.521168] FS:  00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
> [   69.521172] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
> [   69.521179] Call Trace:
> [   69.521182]  <TASK>
> [   69.521185]  ? __pfx_dma_buf_vmap+0x10/0x10
> [   69.521193]  ? dma_resv_get_singleton+0x9a/0x2a0
> [   69.521197]  drm_gem_shmem_vmap_locked+0xc2/0x5f0
> [   69.521208]  ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
> [   69.521212]  ? __pfx_ww_mutex_lock+0x10/0x10
> [   69.521225]  ? sched_clock_noinstr+0xd/0x20
> [   69.521230]  ? local_clock_noinstr+0x13/0xf0
> [   69.521233]  drm_gem_shmem_object_vmap+0xd/0x20
> [   69.521237]  drm_gem_vmap_locked+0x70/0xf0
> [   69.521247]  drm_gem_vmap+0x4c/0xa0
> [   69.521250]  drm_gem_fb_vmap+0xb2/0x3b0
> [   69.521255]  vkms_prepare_fb+0x6f/0x90 [vkms]
> [   69.521264]  ? drm_atomic_helper_setup_commit+0xb7b/0x1320
> [   69.521268]  drm_atomic_helper_prepare_planes+0x19f/0xb90
> [   69.521272]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [   69.521276]  drm_atomic_helper_commit+0x126/0x2d0
> [   69.521279]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
> [   69.521282]  drm_atomic_commit+0x205/0x2d0
> [   69.521290]  ? _raw_spin_lock_irqsave+0x97/0xf0
> [   69.521295]  ? __pfx_drm_atomic_commit+0x10/0x10
> [   69.521299]  ? __pfx___drm_printfn_info+0x10/0x10
> [   69.521313]  ? drm_event_reserve_init+0x1cd/0x260
> [   69.521318]  drm_mode_atomic_ioctl+0x1c79/0x2d30
> [   69.521323]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [   69.521326]  ? __kasan_check_write+0x18/0x20
> [   69.521339]  drm_ioctl_kernel+0x17b/0x2f0
> [   69.521343]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [   69.521349]  ? __pfx_drm_ioctl_kernel+0x10/0x10
> [   69.521353]  ? __pfx_do_vfs_ioctl+0x10/0x10
> [   69.521361]  ? __kasan_check_write+0x18/0x20
> [   69.521365]  drm_ioctl+0x51b/0xbd0
> [   69.521369]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> [   69.521373]  ? __pfx_drm_ioctl+0x10/0x10
> [   69.521378]  ? selinux_file_ioctl+0xfc/0x260
> [   69.521390]  __x64_sys_ioctl+0x143/0x1d0
> [   69.521394]  x64_sys_call+0xf4b/0x1d70
> [   69.521404]  do_syscall_64+0x82/0x2a0
> [   69.521408]  ? __kasan_check_write+0x18/0x20
> [   69.521411]  ? do_user_addr_fault+0x491/0xa60
> [   69.521420]  ? irqentry_exit+0x3f/0x50
> [   69.521423]  ? exc_page_fault+0x8b/0xe0
> [   69.521426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [   69.521430] RIP: 0033:0x7fbc078fd8ed
> [   69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> [   69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [   69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
> [   69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
> [   69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
> [   69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
> [   69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
> [   69.521464]  </TASK>
> [   69.521466] ---[ end trace 0000000000000000 ]---
>
>
>
>> Best regards
>> Thomas
>>
>>> Jose
>>>
>>>> -Sima
>>>>
>>>> -- 
>>>> Simona Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>> -- 
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[José Expósito]

Hi,

On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 13.06.25 um 13:55 schrieb José Expósito:
> > Hi Thomas,
> > 
> > Thanks for the heads up, this issue fall through the cracks.
> > 
> > On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 13.03.25 um 18:20 schrieb José Expósito:
> > > > On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
> > > > > On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
> > > > > > On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
> > > > > > > Hi everyone,
> > > > > > > 
> > > > > > > > On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
> > > > > > > > > Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
> > > > > > > > > > Hi
> > > > > > > > > > 
> > > > > > > > > > Am 10.02.25 um 15:37 schrieb Louis Chauvet:
> > > > > > > > > > > On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
> > > > > > > > > > > > The vkms driver does not need to create a platform device, as there is
> > > > > > > > > > > > no real platform resources associated it,  it only did so because it was
> > > > > > > > > > > > simple to do that in order to get a device to use for resource
> > > > > > > > > > > > management of drm resources.  Change the driver to use the faux device
> > > > > > > > > > > > instead as this is NOT a real platform device.
> > > > > > > > > > > > 
> > > > > > > > > > > > Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > > > Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
> > > > > > > > > > > > Cc: Simona Vetter <simona@ffwll.ch>
> > > > > > > > > > > > Cc: Melissa Wen <melissa.srw@gmail.com>
> > > > > > > > > > > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > > > > > > > > > > Cc: Maxime Ripard <mripard@kernel.org>
> > > > > > > > > > > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > > > > Cc: David Airlie <airlied@gmail.com>
> > > > > > > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > > > > > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > > > > > > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > > > > > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > > > > > > > > > 
> > > > > > > > > > > Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > > Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > > > > > > > > 
> > > > > > > > > > > Thanks for the modification, it seems to work.
> > > > > > > > > > Should this patch be merged through DRM trees? drm-misc-next is at
> > > > > > > > > > v6.14-rc4 and has struct faux_device.
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I was not aware the faux-device was merged, as it is a new feature, I
> > > > > > > > > expected it to reach drm-misc-next on 6.15-rc1.
> > > > > > > > I added it to Linus's tree just so that DRM could get these changes into
> > > > > > > > their tree now :)
> > > > > > > > 
> > > > > > > > > I plan to merge [1] today/tomorrow (well tested with platform_device), and
> > > > > > > > > then I will submit an updated version of this patch (only trivial conflicts,
> > > > > > > > > but never tested with multiple VKMS devices).
> > > > > > > > > 
> > > > > > > > > [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
> > > > > > > > Great, thanks!
> > > > > > > > 
> > > > > > > > greg k-h
> > > > > > > Testing this patch again as part of some IGT tests I'm working on,
> > > > > > > I noticed that, applying this patch on top of the latest drm-misc-next
> > > > > > > triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
> > > > > > > drm_gem_get_pages():
> > > > > > > 
> > > > > > >       if (WARN_ON(!obj->filp))
> > > > > > >               return ERR_PTR(-EINVAL);
> > > > > > I don't see how the faux bus change would have anything to do with a
> > > > > > filp as that's not related as far as I can tell.  But I don't know the
> > > > > > drm layer at all, where does that filp come from?
> > > > > Yeah that filp is the shmem file that backs gem bo. That's very far away
> > > > > from anything device/driver related datastrctures. If this is a new
> > > > > failure due to the aux bux conversion then it would be really surprising.
> > > > Agreed, I find it surprising, but reverting the patch removes the warning.
> > > > 
> > > > It's most likely an issue on my side, but I decided to double check just
> > > > in case someone else is also seeing this warning.
> > > Any news on this issue?
> > I tested again with drm-misc-next. At the moment of writing this, the last
> > commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
> > access rules") and I still see a similar warning. The stack trace changed,
> > but the warning is still present.
> > 
> > I'm going to detail the exact steps I followed. Let's see if someone else is
> > able to reproduce the issue:
> > 
> > I started by applying the patches from this series that are not already merged:
> > 
> >   - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
> >   - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
> >   - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
> >   - [PATCH v4 9/9] drm/vkms: convert to use faux_device
> > 
> > The last patch has small conflict in vkms_drv.h that I solved like this:
> > 
> > 	struct vkms_device {
> > 		struct drm_device drm;
> > 		struct faux_device *faux_dev;
> > 		const struct vkms_config *config;
> > 	};
> > 
> > And in vkms_drv.c:
> > 
> > 	static int vkms_create(struct vkms_config *config)
> > 	{
> > 		int ret;
> > 		struct faux_device *fdev;
> > 		struct vkms_device *vkms_device;
> > 		const char *dev_name;
> > 
> > 		dev_name = vkms_config_get_device_name(config);
> > 		fdev = faux_device_create(dev_name, NULL, NULL);
> > 		if (!fdev)
> > 			return -ENODEV;
> > 
> > Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
> > There is nothing special about my Fedora, it is the regular desktop version.
> > 
> > After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
> > For reference, the warning is at the end of my email.
> > 
> > Am I the only one sawing this warning?
> > 
> > Jose
> > 
> > ---
> > 
> > [   69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
> > [   69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
> > [   69.520944] ------------[ cut here ]------------
> > [   69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
> > [   69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
> > [   69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
> > [   69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> > [   69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
> 
> That's dmabuf. could be related to the fact that there's no real DMA
> possible with the faux_device. We now have support for dmabuf-without-DMA,
> sort of. Could you please replace DRM_GEM_SHMEM_DRIVER_OPS with the new
> DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual
> hardware-DMA functionality.

I don't see the warning anymore :) However, could this change introduce
unexpected side-effects?

Since Louis and Greg didn't see this warning, I'm a bit worried that it
is caused by something unrelated in my dev environment.
If the change can cause other issues, I'd prefer to avoid it. It is weird
that I'm the only one seeing it.

Jose

> [1] https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104
> 
> Best regards
> Thomas
> 
> 
> > [   69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
> > [   69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
> > [   69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
> > [   69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
> > [   69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
> > [   69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
> > [   69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
> > [   69.521168] FS:  00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
> > [   69.521172] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [   69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
> > [   69.521179] Call Trace:
> > [   69.521182]  <TASK>
> > [   69.521185]  ? __pfx_dma_buf_vmap+0x10/0x10
> > [   69.521193]  ? dma_resv_get_singleton+0x9a/0x2a0
> > [   69.521197]  drm_gem_shmem_vmap_locked+0xc2/0x5f0
> > [   69.521208]  ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
> > [   69.521212]  ? __pfx_ww_mutex_lock+0x10/0x10
> > [   69.521225]  ? sched_clock_noinstr+0xd/0x20
> > [   69.521230]  ? local_clock_noinstr+0x13/0xf0
> > [   69.521233]  drm_gem_shmem_object_vmap+0xd/0x20
> > [   69.521237]  drm_gem_vmap_locked+0x70/0xf0
> > [   69.521247]  drm_gem_vmap+0x4c/0xa0
> > [   69.521250]  drm_gem_fb_vmap+0xb2/0x3b0
> > [   69.521255]  vkms_prepare_fb+0x6f/0x90 [vkms]
> > [   69.521264]  ? drm_atomic_helper_setup_commit+0xb7b/0x1320
> > [   69.521268]  drm_atomic_helper_prepare_planes+0x19f/0xb90
> > [   69.521272]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
> > [   69.521276]  drm_atomic_helper_commit+0x126/0x2d0
> > [   69.521279]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
> > [   69.521282]  drm_atomic_commit+0x205/0x2d0
> > [   69.521290]  ? _raw_spin_lock_irqsave+0x97/0xf0
> > [   69.521295]  ? __pfx_drm_atomic_commit+0x10/0x10
> > [   69.521299]  ? __pfx___drm_printfn_info+0x10/0x10
> > [   69.521313]  ? drm_event_reserve_init+0x1cd/0x260
> > [   69.521318]  drm_mode_atomic_ioctl+0x1c79/0x2d30
> > [   69.521323]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [   69.521326]  ? __kasan_check_write+0x18/0x20
> > [   69.521339]  drm_ioctl_kernel+0x17b/0x2f0
> > [   69.521343]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [   69.521349]  ? __pfx_drm_ioctl_kernel+0x10/0x10
> > [   69.521353]  ? __pfx_do_vfs_ioctl+0x10/0x10
> > [   69.521361]  ? __kasan_check_write+0x18/0x20
> > [   69.521365]  drm_ioctl+0x51b/0xbd0
> > [   69.521369]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
> > [   69.521373]  ? __pfx_drm_ioctl+0x10/0x10
> > [   69.521378]  ? selinux_file_ioctl+0xfc/0x260
> > [   69.521390]  __x64_sys_ioctl+0x143/0x1d0
> > [   69.521394]  x64_sys_call+0xf4b/0x1d70
> > [   69.521404]  do_syscall_64+0x82/0x2a0
> > [   69.521408]  ? __kasan_check_write+0x18/0x20
> > [   69.521411]  ? do_user_addr_fault+0x491/0xa60
> > [   69.521420]  ? irqentry_exit+0x3f/0x50
> > [   69.521423]  ? exc_page_fault+0x8b/0xe0
> > [   69.521426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [   69.521430] RIP: 0033:0x7fbc078fd8ed
> > [   69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> > [   69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > [   69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
> > [   69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
> > [   69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
> > [   69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
> > [   69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
> > [   69.521464]  </TASK>
> > [   69.521466] ---[ end trace 0000000000000000 ]---
> > 
> > 
> > 
> > > Best regards
> > > Thomas
> > > 
> > > > Jose
> > > > 
> > > > > -Sima
> > > > > 
> > > > > -- 
> > > > > Simona Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > > -- 
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Frankenstrasse 146, 90461 Nuernberg, Germany
> > > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> > > HRB 36809 (AG Nuernberg)
> > > 
> 
> -- 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
> 

Re: [PATCH v4 9/9] drm/vkms: convert to use faux_device

[Thomas Zimmermann]

Hi

Am 13.06.25 um 17:28 schrieb José Expósito:
> Hi,
>
> On Fri, Jun 13, 2025 at 02:33:36PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 13.06.25 um 13:55 schrieb José Expósito:
>>> Hi Thomas,
>>>
>>> Thanks for the heads up, this issue fall through the cracks.
>>>
>>> On Fri, Jun 13, 2025 at 10:15:05AM +0200, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 13.03.25 um 18:20 schrieb José Expósito:
>>>>> On Thu, Mar 13, 2025 at 03:22:21PM +0100, Simona Vetter wrote:
>>>>>> On Wed, Mar 12, 2025 at 07:22:07AM +0100, Greg KH wrote:
>>>>>>> On Tue, Mar 11, 2025 at 06:20:53PM +0100, José Expósito wrote:
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>>> On Tue, Feb 25, 2025 at 02:51:40PM +0100, Louis Chauvet wrote:
>>>>>>>>>> Le 25/02/2025 à 12:41, Thomas Zimmermann a écrit :
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Am 10.02.25 um 15:37 schrieb Louis Chauvet:
>>>>>>>>>>>> On 10/02/25 - 13:30, Greg Kroah-Hartman wrote:
>>>>>>>>>>>>> The vkms driver does not need to create a platform device, as there is
>>>>>>>>>>>>> no real platform resources associated it,  it only did so because it was
>>>>>>>>>>>>> simple to do that in order to get a device to use for resource
>>>>>>>>>>>>> management of drm resources.  Change the driver to use the faux device
>>>>>>>>>>>>> instead as this is NOT a real platform device.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>>> Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
>>>>>>>>>>>>> Cc: Simona Vetter <simona@ffwll.ch>
>>>>>>>>>>>>> Cc: Melissa Wen <melissa.srw@gmail.com>
>>>>>>>>>>>>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>>>>>>>> Cc: Maxime Ripard <mripard@kernel.org>
>>>>>>>>>>>>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>>>> Cc: David Airlie <airlied@gmail.com>
>>>>>>>>>>>>> Cc: dri-devel@lists.freedesktop.org
>>>>>>>>>>>>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>>>>>>>>>>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>>>>>
>>>>>>>>>>>> Tested-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the modification, it seems to work.
>>>>>>>>>>> Should this patch be merged through DRM trees? drm-misc-next is at
>>>>>>>>>>> v6.14-rc4 and has struct faux_device.
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I was not aware the faux-device was merged, as it is a new feature, I
>>>>>>>>>> expected it to reach drm-misc-next on 6.15-rc1.
>>>>>>>>> I added it to Linus's tree just so that DRM could get these changes into
>>>>>>>>> their tree now :)
>>>>>>>>>
>>>>>>>>>> I plan to merge [1] today/tomorrow (well tested with platform_device), and
>>>>>>>>>> then I will submit an updated version of this patch (only trivial conflicts,
>>>>>>>>>> but never tested with multiple VKMS devices).
>>>>>>>>>>
>>>>>>>>>> [1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposito89@gmail.com/
>>>>>>>>> Great, thanks!
>>>>>>>>>
>>>>>>>>> greg k-h
>>>>>>>> Testing this patch again as part of some IGT tests I'm working on,
>>>>>>>> I noticed that, applying this patch on top of the latest drm-misc-next
>>>>>>>> triggers a warning at drivers/gpu/drm/drm_gem.c:571, in
>>>>>>>> drm_gem_get_pages():
>>>>>>>>
>>>>>>>>        if (WARN_ON(!obj->filp))
>>>>>>>>                return ERR_PTR(-EINVAL);
>>>>>>> I don't see how the faux bus change would have anything to do with a
>>>>>>> filp as that's not related as far as I can tell.  But I don't know the
>>>>>>> drm layer at all, where does that filp come from?
>>>>>> Yeah that filp is the shmem file that backs gem bo. That's very far away
>>>>>> from anything device/driver related datastrctures. If this is a new
>>>>>> failure due to the aux bux conversion then it would be really surprising.
>>>>> Agreed, I find it surprising, but reverting the patch removes the warning.
>>>>>
>>>>> It's most likely an issue on my side, but I decided to double check just
>>>>> in case someone else is also seeing this warning.
>>>> Any news on this issue?
>>> I tested again with drm-misc-next. At the moment of writing this, the last
>>> commit is 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the safe
>>> access rules") and I still see a similar warning. The stack trace changed,
>>> but the warning is still present.
>>>
>>> I'm going to detail the exact steps I followed. Let's see if someone else is
>>> able to reproduce the issue:
>>>
>>> I started by applying the patches from this series that are not already merged:
>>>
>>>    - [PATCH v4 4/9] x86/microcode: move away from using a fake platform
>>>    - [PATCH v4 5/9] wifi: cfg80211: move away from using a fake
>>>    - [PATCH v4 8/9] drm/vgem/vgem_drv convert to use faux_device
>>>    - [PATCH v4 9/9] drm/vkms: convert to use faux_device
>>>
>>> The last patch has small conflict in vkms_drv.h that I solved like this:
>>>
>>> 	struct vkms_device {
>>> 		struct drm_device drm;
>>> 		struct faux_device *faux_dev;
>>> 		const struct vkms_config *config;
>>> 	};
>>>
>>> And in vkms_drv.c:
>>>
>>> 	static int vkms_create(struct vkms_config *config)
>>> 	{
>>> 		int ret;
>>> 		struct faux_device *fdev;
>>> 		struct vkms_device *vkms_device;
>>> 		const char *dev_name;
>>>
>>> 		dev_name = vkms_config_get_device_name(config);
>>> 		fdev = faux_device_create(dev_name, NULL, NULL);
>>> 		if (!fdev)
>>> 			return -ENODEV;
>>>
>>> Next, I installed the new kernel in a QEMU virtual machine running Fedora 41.
>>> There is nothing special about my Fedora, it is the regular desktop version.
>>>
>>> After a reboot, "sudo modprobe vkms" shows a similar warning in dmesg.
>>> For reference, the warning is at the end of my email.
>>>
>>> Am I the only one sawing this warning?
>>>
>>> Jose
>>>
>>> ---
>>>
>>> [   69.417850] [drm] Initialized vkms 1.0.0 for vkms on minor 1
>>> [   69.419446] faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device
>>> [   69.520944] ------------[ cut here ]------------
>>> [   69.520954] WARNING: CPU: 2 PID: 1015 at drivers/dma-buf/dma-buf.c:1518 dma_buf_vmap+0x212/0x540
>>> [   69.520992] Modules linked in: vkms snd_seq_dummy snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill qrtr sunrpc binfmt_misc ppdev pktcdvd parport_pc parport pcspkr i2c_piix4 e1000 i2c_smbus joydev loop nfnetlink vsock_loopback zram vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bochs serio_raw ata_generic pata_acpi fuse qemu_fw_cfg
>>> [   69.521082] CPU: 2 UID: 42 PID: 1015 Comm: KMS thread Not tainted 6.16.0-rc1+ #3 PREEMPT(voluntary)
>>> [   69.521092] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
>>> [   69.521095] RIP: 0010:dma_buf_vmap+0x212/0x540
>> That's dmabuf. could be related to the fact that there's no real DMA
>> possible with the faux_device. We now have support for dmabuf-without-DMA,
>> sort of. Could you please replace DRM_GEM_SHMEM_DRIVER_OPS with the new
>> DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT at [1]. That would avoid any actual
>> hardware-DMA functionality.
> I don't see the warning anymore :) However, could this change introduce
> unexpected side-effects?

Great that it works. I plan to roll this out for most of the 
GEM-SHMEM-based drivers and it will hopefully not cause any problems.

>
> Since Louis and Greg didn't see this warning, I'm a bit worried that it
> is caused by something unrelated in my dev environment.
> If the change can cause other issues, I'd prefer to avoid it. It is weird
> that I'm the only one seeing it.

Could be related to the test environment, but I cannot point to the 
difference.

Best regards
Thomas

>
> Jose
>
>> [1] https://elixir.bootlin.com/linux/v6.15.1/source/drivers/gpu/drm/vkms/vkms_drv.c#L104
>>
>> Best regards
>> Thomas
>>
>>
>>> [   69.521105] Code: 7c 41 ff 03 0f 85 0a 02 00 00 c9 e9 c8 47 0c 01 80 3c 06 00 0f 85 c4 01 00 00 48 c7 01 00 00 00 00 48 85 d2 0f 85 bd fe ff ff <0f> 0b b8 ea ff ff ff eb af 48 85 f6 0f 85 cf 01 00 00 48 89 4c 24
>>> [   69.521112] RSP: 0018:ffffc90006a5f690 EFLAGS: 00010246
>>> [   69.521125] RAX: dffffc0000000000 RBX: 1ffff92000d4beea RCX: ffff88811467dcc8
>>> [   69.521128] RDX: 0000000000000000 RSI: 1ffff110228cfb99 RDI: ffff88811467dcd0
>>> [   69.521131] RBP: ffffc90006a5f728 R08: 1ffff92000d4bed9 R09: fffff52000d4bef1
>>> [   69.521162] R10: fffff52000d4bef2 R11: ffff8881017f4e28 R12: ffff8881149594f0
>>> [   69.521165] R13: ffff888114959400 R14: 1ffff11023146b29 R15: ffff88811467dcc8
>>> [   69.521168] FS:  00007fbbdd1ff6c0(0000) GS:ffff888417580000(0000) knlGS:0000000000000000
>>> [   69.521172] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [   69.521174] CR2: 00007fbbcc0345c8 CR3: 000000011ec5a000 CR4: 00000000000006f0
>>> [   69.521179] Call Trace:
>>> [   69.521182]  <TASK>
>>> [   69.521185]  ? __pfx_dma_buf_vmap+0x10/0x10
>>> [   69.521193]  ? dma_resv_get_singleton+0x9a/0x2a0
>>> [   69.521197]  drm_gem_shmem_vmap_locked+0xc2/0x5f0
>>> [   69.521208]  ? __pfx_drm_gem_shmem_vmap_locked+0x10/0x10
>>> [   69.521212]  ? __pfx_ww_mutex_lock+0x10/0x10
>>> [   69.521225]  ? sched_clock_noinstr+0xd/0x20
>>> [   69.521230]  ? local_clock_noinstr+0x13/0xf0
>>> [   69.521233]  drm_gem_shmem_object_vmap+0xd/0x20
>>> [   69.521237]  drm_gem_vmap_locked+0x70/0xf0
>>> [   69.521247]  drm_gem_vmap+0x4c/0xa0
>>> [   69.521250]  drm_gem_fb_vmap+0xb2/0x3b0
>>> [   69.521255]  vkms_prepare_fb+0x6f/0x90 [vkms]
>>> [   69.521264]  ? drm_atomic_helper_setup_commit+0xb7b/0x1320
>>> [   69.521268]  drm_atomic_helper_prepare_planes+0x19f/0xb90
>>> [   69.521272]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
>>> [   69.521276]  drm_atomic_helper_commit+0x126/0x2d0
>>> [   69.521279]  ? __pfx_drm_atomic_helper_commit+0x10/0x10
>>> [   69.521282]  drm_atomic_commit+0x205/0x2d0
>>> [   69.521290]  ? _raw_spin_lock_irqsave+0x97/0xf0
>>> [   69.521295]  ? __pfx_drm_atomic_commit+0x10/0x10
>>> [   69.521299]  ? __pfx___drm_printfn_info+0x10/0x10
>>> [   69.521313]  ? drm_event_reserve_init+0x1cd/0x260
>>> [   69.521318]  drm_mode_atomic_ioctl+0x1c79/0x2d30
>>> [   69.521323]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [   69.521326]  ? __kasan_check_write+0x18/0x20
>>> [   69.521339]  drm_ioctl_kernel+0x17b/0x2f0
>>> [   69.521343]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [   69.521349]  ? __pfx_drm_ioctl_kernel+0x10/0x10
>>> [   69.521353]  ? __pfx_do_vfs_ioctl+0x10/0x10
>>> [   69.521361]  ? __kasan_check_write+0x18/0x20
>>> [   69.521365]  drm_ioctl+0x51b/0xbd0
>>> [   69.521369]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
>>> [   69.521373]  ? __pfx_drm_ioctl+0x10/0x10
>>> [   69.521378]  ? selinux_file_ioctl+0xfc/0x260
>>> [   69.521390]  __x64_sys_ioctl+0x143/0x1d0
>>> [   69.521394]  x64_sys_call+0xf4b/0x1d70
>>> [   69.521404]  do_syscall_64+0x82/0x2a0
>>> [   69.521408]  ? __kasan_check_write+0x18/0x20
>>> [   69.521411]  ? do_user_addr_fault+0x491/0xa60
>>> [   69.521420]  ? irqentry_exit+0x3f/0x50
>>> [   69.521423]  ? exc_page_fault+0x8b/0xe0
>>> [   69.521426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>> [   69.521430] RIP: 0033:0x7fbc078fd8ed
>>> [   69.521441] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
>>> [   69.521444] RSP: 002b:00007fbbdd1fd9b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
>>> [   69.521449] RAX: ffffffffffffffda RBX: 00007fbbcc02af60 RCX: 00007fbc078fd8ed
>>> [   69.521452] RDX: 00007fbbdd1fda50 RSI: 00000000c03864bc RDI: 0000000000000035
>>> [   69.521455] RBP: 00007fbbdd1fda00 R08: 00000000000000e0 R09: 0000000000000001
>>> [   69.521457] R10: 0000000000000003 R11: 0000000000000246 R12: 00007fbbdd1fda50
>>> [   69.521459] R13: 00000000c03864bc R14: 0000000000000035 R15: 00007fbbcc02acf0
>>> [   69.521464]  </TASK>
>>> [   69.521466] ---[ end trace 0000000000000000 ]---
>>>
>>>
>>>
>>>> Best regards
>>>> Thomas
>>>>
>>>>> Jose
>>>>>
>>>>>> -Sima
>>>>>>
>>>>>> -- 
>>>>>> Simona Vetter
>>>>>> Software Engineer, Intel Corporation
>>>>>> http://blog.ffwll.ch
>>>> -- 
>>>> --
>>>> Thomas Zimmermann
>>>> Graphics Driver Developer
>>>> SUSE Software Solutions Germany GmbH
>>>> Frankenstrasse 146, 90461 Nuernberg, Germany
>>>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>>>> HRB 36809 (AG Nuernberg)
>>>>
>> -- 
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)