Re: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-13 Thread Thomas Zimmermann

Hi

Am 13.09.22 um 17:15 schrieb Saurabh Singh Sengar:

On Mon, Sep 12, 2022 at 09:03:53AM +0200, Thomas Zimmermann wrote:

Hi

Am 11.09.22 um 18:21 schrieb Saurabh Singh Sengar:

On Sat, Sep 10, 2022 at 08:11:24PM +0200, Thomas Zimmermann wrote:

Hi

Am 09.09.22 um 16:43 schrieb Saurabh Sengar:

hyperv_setup_vram tries to remove conflicting framebuffer based on
'screen_info'. As observed in past due to some bug or wrong setting
in grub, the 'screen_info' fields may not be set for Gen1, and in such
cases drm_aperture_remove_conflicting_framebuffers will not do anything
useful.
For Gen1 VMs, it should always be possible to get framebuffer
conflict removed using PCI device instead.

Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM allocation with 
PCI bar size")
Signed-off-by: Saurabh Sengar 
---
  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 6d11e7938c83..b0cc974efa45 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device *hv,
 struct hv_device *hdev)
  {
struct drm_device *dev = >dev;
+   struct pci_dev *pdev;
int ret;
-   drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
-screen_info.lfb_size,
-false,
-_driver);
+   if (efi_enabled(EFI_BOOT)) {
+   
drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
+
screen_info.lfb_size,


Using screen_info here seems wrong in any case. You want to remove
the framebuffer devices that conflict with your driver, which might
be unrelated to screen_info. AFAICT the correct solution would
always retrieve the PCI device for removal (i.e., always do the else
branch).


In a Gen2 VM, the Hyper-V frame buffer device is presented only as a VMbus 
device.
It's not presented as a PCI device like it is in a Gen1 VM. This would have 
worked
if we had the frame buffer device available as PCI device in Gen2 but 
unfortunately
thats not the case here.


Thanks for explaining. There is an instance of struct hv_device
passed to the probe function. I suspect you cannot get the
framebuffer range from this instance (e.g., via the device's
platform_data)?

If you absolutely can't get the actual memory region from the
device, it's better to remove all framebuffers via
drm_aperture_remove_framebuffers() than to use screen_info.

Best regards
Thomas


Thanks for your suggestion, and I thought of using 
drm_aperture_remove_framebuffers
here, but this driver will be used in many different systems with many other 
graphics
devices (GPU etc). Removing all the framebuffer is a bit blunt approach which 
may disturb
the devices we are not intended to and which are even outside of the HyperV 
MMIO region.
I feel this API use will be risky, and I would like to stick to the earlier 
method which
is proven to be working for many years and we are sure it won't disturb anyone 
outside
MMIO region.


But the problem with the current code is that you also remove the driver 
that covers the boot-up graphics, even if it's not even a hyperv device. 
That's why I said that you should try to detect if the hyperv device 
you're creating actually uses the screen_info when you create the device.


Set that information as device data and look it up in the hyperv-drm 
driver. If no such screen_info data is attached to the device, you don't 
have to remove conflicting framebuffers at all.


Best regards
Thomas



Regards,
Saurabh




Regards,
Saurabh



Best regard
Thomas


+false,
+_driver);
+   } else {
+   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
+   if (!pdev) {
+   drm_err(dev, "Unable to find PCI Hyper-V video\n");
+   return -ENODEV;
+   }
+
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
+   pci_dev_put(pdev);
+   if (ret) {
+   drm_err(dev, "Not able to remove boot fb\n");
+   return ret;
+   }
+   }
hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev






--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH

Re: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-13 Thread Saurabh Singh Sengar
On Mon, Sep 12, 2022 at 09:03:53AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 11.09.22 um 18:21 schrieb Saurabh Singh Sengar:
> >On Sat, Sep 10, 2022 at 08:11:24PM +0200, Thomas Zimmermann wrote:
> >>Hi
> >>
> >>Am 09.09.22 um 16:43 schrieb Saurabh Sengar:
> >>>hyperv_setup_vram tries to remove conflicting framebuffer based on
> >>>'screen_info'. As observed in past due to some bug or wrong setting
> >>>in grub, the 'screen_info' fields may not be set for Gen1, and in such
> >>>cases drm_aperture_remove_conflicting_framebuffers will not do anything
> >>>useful.
> >>>For Gen1 VMs, it should always be possible to get framebuffer
> >>>conflict removed using PCI device instead.
> >>>
> >>>Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM 
> >>>allocation with PCI bar size")
> >>>Signed-off-by: Saurabh Sengar 
> >>>---
> >>>  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
> >>>  1 file changed, 20 insertions(+), 4 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
> >>>b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >>>index 6d11e7938c83..b0cc974efa45 100644
> >>>--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >>>+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >>>@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device 
> >>>*hv,
> >>>struct hv_device *hdev)
> >>>  {
> >>>   struct drm_device *dev = >dev;
> >>>+  struct pci_dev *pdev;
> >>>   int ret;
> >>>-  drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> >>>-   screen_info.lfb_size,
> >>>-   false,
> >>>-   _driver);
> >>>+  if (efi_enabled(EFI_BOOT)) {
> >>>+  
> >>>drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> >>>+   
> >>>screen_info.lfb_size,
> >>
> >>Using screen_info here seems wrong in any case. You want to remove
> >>the framebuffer devices that conflict with your driver, which might
> >>be unrelated to screen_info. AFAICT the correct solution would
> >>always retrieve the PCI device for removal (i.e., always do the else
> >>branch).
> >
> >In a Gen2 VM, the Hyper-V frame buffer device is presented only as a VMbus 
> >device.
> >It's not presented as a PCI device like it is in a Gen1 VM. This would have 
> >worked
> >if we had the frame buffer device available as PCI device in Gen2 but 
> >unfortunately
> >thats not the case here.
> 
> Thanks for explaining. There is an instance of struct hv_device
> passed to the probe function. I suspect you cannot get the
> framebuffer range from this instance (e.g., via the device's
> platform_data)?
> 
> If you absolutely can't get the actual memory region from the
> device, it's better to remove all framebuffers via
> drm_aperture_remove_framebuffers() than to use screen_info.
> 
> Best regards
> Thomas

Thanks for your suggestion, and I thought of using 
drm_aperture_remove_framebuffers
here, but this driver will be used in many different systems with many other 
graphics
devices (GPU etc). Removing all the framebuffer is a bit blunt approach which 
may disturb
the devices we are not intended to and which are even outside of the HyperV 
MMIO region.
I feel this API use will be risky, and I would like to stick to the earlier 
method which
is proven to be working for many years and we are sure it won't disturb anyone 
outside
MMIO region.

Regards,
Saurabh
> 
> >
> >Regards,
> >Saurabh
> >
> >>
> >>Best regard
> >>Thomas
> >>
> >>>+   false,
> >>>+   _driver);
> >>>+  } else {
> >>>+  pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
> >>>PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> >>>+  if (!pdev) {
> >>>+  drm_err(dev, "Unable to find PCI Hyper-V video\n");
> >>>+  return -ENODEV;
> >>>+  }
> >>>+
> >>>+  ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
> >>>_driver);
> >>>+  pci_dev_put(pdev);
> >>>+  if (ret) {
> >>>+  drm_err(dev, "Not able to remove boot fb\n");
> >>>+  return ret;
> >>>+  }
> >>>+  }
> >>>   hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
> >>
> >>-- 
> >>Thomas Zimmermann
> >>Graphics Driver Developer
> >>SUSE Software Solutions Germany GmbH
> >>Maxfeldstr. 5, 90409 Nürnberg, Germany
> >>(HRB 36809, AG Nürnberg)
> >>Geschäftsführer: Ivo Totev
> >
> >
> >
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev





Re: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-12 Thread Thomas Zimmermann

Hi

Am 11.09.22 um 18:21 schrieb Saurabh Singh Sengar:

On Sat, Sep 10, 2022 at 08:11:24PM +0200, Thomas Zimmermann wrote:

Hi

Am 09.09.22 um 16:43 schrieb Saurabh Sengar:

hyperv_setup_vram tries to remove conflicting framebuffer based on
'screen_info'. As observed in past due to some bug or wrong setting
in grub, the 'screen_info' fields may not be set for Gen1, and in such
cases drm_aperture_remove_conflicting_framebuffers will not do anything
useful.
For Gen1 VMs, it should always be possible to get framebuffer
conflict removed using PCI device instead.

Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM allocation with 
PCI bar size")
Signed-off-by: Saurabh Sengar 
---
  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 6d11e7938c83..b0cc974efa45 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device *hv,
 struct hv_device *hdev)
  {
struct drm_device *dev = >dev;
+   struct pci_dev *pdev;
int ret;
-   drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
-screen_info.lfb_size,
-false,
-_driver);
+   if (efi_enabled(EFI_BOOT)) {
+   
drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
+
screen_info.lfb_size,


Using screen_info here seems wrong in any case. You want to remove
the framebuffer devices that conflict with your driver, which might
be unrelated to screen_info. AFAICT the correct solution would
always retrieve the PCI device for removal (i.e., always do the else
branch).


In a Gen2 VM, the Hyper-V frame buffer device is presented only as a VMbus 
device.
It's not presented as a PCI device like it is in a Gen1 VM. This would have 
worked
if we had the frame buffer device available as PCI device in Gen2 but 
unfortunately
thats not the case here.


Thanks for explaining. There is an instance of struct hv_device passed 
to the probe function. I suspect you cannot get the framebuffer range 
from this instance (e.g., via the device's platform_data)?


If you absolutely can't get the actual memory region from the device, 
it's better to remove all framebuffers via 
drm_aperture_remove_framebuffers() than to use screen_info.


Best regards
Thomas



Regards,
Saurabh



Best regard
Thomas


+false,
+_driver);
+   } else {
+   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
+   if (!pdev) {
+   drm_err(dev, "Unable to find PCI Hyper-V video\n");
+   return -ENODEV;
+   }
+
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
+   pci_dev_put(pdev);
+   if (ret) {
+   drm_err(dev, "Not able to remove boot fb\n");
+   return ret;
+   }
+   }
hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev






--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-11 Thread Saurabh Singh Sengar
On Sat, Sep 10, 2022 at 08:11:24PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.09.22 um 16:43 schrieb Saurabh Sengar:
> >hyperv_setup_vram tries to remove conflicting framebuffer based on
> >'screen_info'. As observed in past due to some bug or wrong setting
> >in grub, the 'screen_info' fields may not be set for Gen1, and in such
> >cases drm_aperture_remove_conflicting_framebuffers will not do anything
> >useful.
> >For Gen1 VMs, it should always be possible to get framebuffer
> >conflict removed using PCI device instead.
> >
> >Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM 
> >allocation with PCI bar size")
> >Signed-off-by: Saurabh Sengar 
> >---
> >  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
> >  1 file changed, 20 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
> >b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >index 6d11e7938c83..b0cc974efa45 100644
> >--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> >@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device 
> >*hv,
> >  struct hv_device *hdev)
> >  {
> > struct drm_device *dev = >dev;
> >+struct pci_dev *pdev;
> > int ret;
> >-drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> >- screen_info.lfb_size,
> >- false,
> >- _driver);
> >+if (efi_enabled(EFI_BOOT)) {
> >+
> >drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> >+ 
> >screen_info.lfb_size,
> 
> Using screen_info here seems wrong in any case. You want to remove
> the framebuffer devices that conflict with your driver, which might
> be unrelated to screen_info. AFAICT the correct solution would
> always retrieve the PCI device for removal (i.e., always do the else
> branch).

In a Gen2 VM, the Hyper-V frame buffer device is presented only as a VMbus 
device.
It's not presented as a PCI device like it is in a Gen1 VM. This would have 
worked
if we had the frame buffer device available as PCI device in Gen2 but 
unfortunately
thats not the case here.

Regards,
Saurabh

> 
> Best regard
> Thomas
> 
> >+ false,
> >+ _driver);
> >+} else {
> >+pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
> >PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> >+if (!pdev) {
> >+drm_err(dev, "Unable to find PCI Hyper-V video\n");
> >+return -ENODEV;
> >+}
> >+
> >+ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
> >_driver);
> >+pci_dev_put(pdev);
> >+if (ret) {
> >+drm_err(dev, "Not able to remove boot fb\n");
> >+return ret;
> >+}
> >+}
> > hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev





Re: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-10 Thread Thomas Zimmermann

Hi

Am 09.09.22 um 16:43 schrieb Saurabh Sengar:

hyperv_setup_vram tries to remove conflicting framebuffer based on
'screen_info'. As observed in past due to some bug or wrong setting
in grub, the 'screen_info' fields may not be set for Gen1, and in such
cases drm_aperture_remove_conflicting_framebuffers will not do anything
useful.
For Gen1 VMs, it should always be possible to get framebuffer
conflict removed using PCI device instead.

Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM allocation with 
PCI bar size")
Signed-off-by: Saurabh Sengar 
---
  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 6d11e7938c83..b0cc974efa45 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device *hv,
 struct hv_device *hdev)
  {
struct drm_device *dev = >dev;
+   struct pci_dev *pdev;
int ret;
  
-	drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,

-screen_info.lfb_size,
-false,
-_driver);
+   if (efi_enabled(EFI_BOOT)) {
+   
drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
+
screen_info.lfb_size,


Using screen_info here seems wrong in any case. You want to remove the 
framebuffer devices that conflict with your driver, which might be 
unrelated to screen_info. AFAICT the correct solution would always 
retrieve the PCI device for removal (i.e., always do the else branch).


Best regard
Thomas


+false,
+_driver);
+   } else {
+   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
+   if (!pdev) {
+   drm_err(dev, "Unable to find PCI Hyper-V video\n");
+   return -ENODEV;
+   }
+
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
+   pci_dev_put(pdev);
+   if (ret) {
+   drm_err(dev, "Not able to remove boot fb\n");
+   return ret;
+   }
+   }
  
  	hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
  


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature


RE: [PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-10 Thread Michael Kelley (LINUX)
From: Saurabh Sengar  Sent: Friday, September 9, 
2022 7:44 AM
> 
> hyperv_setup_vram tries to remove conflicting framebuffer based on
> 'screen_info'. As observed in past due to some bug or wrong setting
> in grub, the 'screen_info' fields may not be set for Gen1, and in such
> cases drm_aperture_remove_conflicting_framebuffers will not do anything
> useful.
> For Gen1 VMs, it should always be possible to get framebuffer
> conflict removed using PCI device instead.
> 
> Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM 
> allocation with PCI bar size")
> Signed-off-by: Saurabh Sengar 
> ---
>  drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index 6d11e7938c83..b0cc974efa45 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device *hv,
>struct hv_device *hdev)
>  {
>   struct drm_device *dev = >dev;
> + struct pci_dev *pdev;
>   int ret;
> 
> - drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> -  screen_info.lfb_size,
> -  false,
> -  _driver);
> + if (efi_enabled(EFI_BOOT)) {
> + 
> drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
> +  
> screen_info.lfb_size,
> +  false,
> +  _driver);
> + } else {
> + pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
> PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
> + if (!pdev) {
> + drm_err(dev, "Unable to find PCI Hyper-V video\n");
> + return -ENODEV;
> + }
> +
> + ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
> _driver);
> + pci_dev_put(pdev);
> + if (ret) {
> + drm_err(dev, "Not able to remove boot fb\n");
> + return ret;
> + }
> + }
> 
>   hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
> 
> --
> 2.34.1

Reviewed-by: Michael Kelley 


[PATCH] drm/hyperv: Don't rely on screen_info.lfb_base for Gen1 VMs

2022-09-09 Thread Saurabh Sengar
hyperv_setup_vram tries to remove conflicting framebuffer based on
'screen_info'. As observed in past due to some bug or wrong setting
in grub, the 'screen_info' fields may not be set for Gen1, and in such
cases drm_aperture_remove_conflicting_framebuffers will not do anything
useful.
For Gen1 VMs, it should always be possible to get framebuffer
conflict removed using PCI device instead.

Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM allocation 
with PCI bar size")
Signed-off-by: Saurabh Sengar 
---
 drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c 
b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
index 6d11e7938c83..b0cc974efa45 100644
--- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
+++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
@@ -73,12 +73,28 @@ static int hyperv_setup_vram(struct hyperv_drm_device *hv,
 struct hv_device *hdev)
 {
struct drm_device *dev = >dev;
+   struct pci_dev *pdev;
int ret;
 
-   drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
-screen_info.lfb_size,
-false,
-_driver);
+   if (efi_enabled(EFI_BOOT)) {
+   
drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
+
screen_info.lfb_size,
+false,
+_driver);
+   } else {
+   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT, 
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
+   if (!pdev) {
+   drm_err(dev, "Unable to find PCI Hyper-V video\n");
+   return -ENODEV;
+   }
+
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
+   pci_dev_put(pdev);
+   if (ret) {
+   drm_err(dev, "Not able to remove boot fb\n");
+   return ret;
+   }
+   }
 
hv->fb_size = (unsigned long)hv->mmio_megabytes * 1024 * 1024;
 
-- 
2.34.1