diff mbox series

[bionic:linux-azure-4.15,focal:linux-azure,groovy:linux-azure] video: hyperv_fb: Fix the cache type when mapping the VRAM

Message ID 20210118212628.3574191-1-marcelo.cerri@canonical.com
State New
Headers show
Series [bionic:linux-azure-4.15,focal:linux-azure,groovy:linux-azure] video: hyperv_fb: Fix the cache type when mapping the VRAM | expand

Commit Message

Marcelo Henrique Cerri Jan. 18, 2021, 9:26 p.m. UTC 
From: Dexuan Cui <decui@microsoft.com>

BugLink: https://bugs.launchpad.net/bugs/1908569

x86 Hyper-V used to essentially always overwrite the effective cache type
of guest memory accesses to WB. This was problematic in cases where there
is a physical device assigned to the VM, since that often requires that
the VM should have control over cache types. Thus, on newer Hyper-V since
2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
users start to complain that Linux VM's VRAM becomes very slow, and it
turns out that Linux VM should not map the VRAM uncacheable by ioremap().
Fix this slowness issue by using ioremap_cache().

On ARM64, ioremap_cache() is also required as the host also maps the VRAM
cacheable, otherwise VM Connect can't display properly with ioremap() or
ioremap_wc().

With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
it's no longer necessary to use the hacks we added to mitigate the
slowness, i.e. we no longer need to allocate physical memory and use
it to back up the VRAM in Generation-1 VM, and we also no longer need to
allocate physical memory to back up the framebuffer in a Generation-2 VM
and copy the framebuffer to the real VRAM. A further big change will
address these for v5.11.

Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
Tested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
(cherry picked from commit 5f1251a48c17b54939d7477305e39679a565382c)
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
---
 drivers/video/fbdev/hyperv_fb.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Comments

Stefan Bader Jan. 21, 2021, 8:32 a.m. UTC | #1 
On 18.01.21 22:26, Marcelo Henrique Cerri wrote:
> From: Dexuan Cui <decui@microsoft.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1908569
> 
> x86 Hyper-V used to essentially always overwrite the effective cache type
> of guest memory accesses to WB. This was problematic in cases where there
> is a physical device assigned to the VM, since that often requires that
> the VM should have control over cache types. Thus, on newer Hyper-V since
> 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
> users start to complain that Linux VM's VRAM becomes very slow, and it
> turns out that Linux VM should not map the VRAM uncacheable by ioremap().
> Fix this slowness issue by using ioremap_cache().
> 
> On ARM64, ioremap_cache() is also required as the host also maps the VRAM
> cacheable, otherwise VM Connect can't display properly with ioremap() or
> ioremap_wc().
> 
> With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
> it's no longer necessary to use the hacks we added to mitigate the
> slowness, i.e. we no longer need to allocate physical memory and use
> it to back up the VRAM in Generation-1 VM, and we also no longer need to
> allocate physical memory to back up the framebuffer in a Generation-2 VM
> and copy the framebuffer to the real VRAM. A further big change will
> address these for v5.11.
> 
> Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
> Tested-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> (cherry picked from commit 5f1251a48c17b54939d7477305e39679a565382c)
> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  drivers/video/fbdev/hyperv_fb.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index fe4731f97df7..aad4eea522a9 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -705,7 +705,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
>  		goto err1;
>  	}
>  
> -	fb_virt = ioremap(par->mem->start, screen_fb_size);
> +	/*
> +	 * Map the VRAM cacheable for performance. This is also required for
> +	 * VM Connect to display properly for ARM64 Linux VM, as the host also
> +	 * maps the VRAM cacheable.
> +	 */
> +	fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
>  	if (!fb_virt)
>  		goto err2;
>  
>
William Breathitt Gray Jan. 21, 2021, 8:39 a.m. UTC | #2 
On Mon, Jan 18, 2021 at 06:26:28PM -0300, Marcelo Henrique Cerri wrote:
> From: Dexuan Cui <decui@microsoft.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1908569
> 
> x86 Hyper-V used to essentially always overwrite the effective cache type
> of guest memory accesses to WB. This was problematic in cases where there
> is a physical device assigned to the VM, since that often requires that
> the VM should have control over cache types. Thus, on newer Hyper-V since
> 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
> users start to complain that Linux VM's VRAM becomes very slow, and it
> turns out that Linux VM should not map the VRAM uncacheable by ioremap().
> Fix this slowness issue by using ioremap_cache().
> 
> On ARM64, ioremap_cache() is also required as the host also maps the VRAM
> cacheable, otherwise VM Connect can't display properly with ioremap() or
> ioremap_wc().
> 
> With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
> it's no longer necessary to use the hacks we added to mitigate the
> slowness, i.e. we no longer need to allocate physical memory and use
> it to back up the VRAM in Generation-1 VM, and we also no longer need to
> allocate physical memory to back up the framebuffer in a Generation-2 VM
> and copy the framebuffer to the real VRAM. A further big change will
> address these for v5.11.
> 
> Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
> Tested-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> (cherry picked from commit 5f1251a48c17b54939d7477305e39679a565382c)
> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
> ---
>  drivers/video/fbdev/hyperv_fb.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index fe4731f97df7..aad4eea522a9 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -705,7 +705,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
>  		goto err1;
>  	}
>  
> -	fb_virt = ioremap(par->mem->start, screen_fb_size);
> +	/*
> +	 * Map the VRAM cacheable for performance. This is also required for
> +	 * VM Connect to display properly for ARM64 Linux VM, as the host also
> +	 * maps the VRAM cacheable.
> +	 */
> +	fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
>  	if (!fb_virt)
>  		goto err2;
>  
> -- 
> 2.25.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: William Breathitt Gray <william.gray@canonical.com>
Kelsey Skunberg Jan. 26, 2021, 6:12 a.m. UTC | #3 
Applied to each master-next. thank you! 

-Kelsey

On 2021-01-18 18:26:28 , Marcelo Henrique Cerri wrote:
> From: Dexuan Cui <decui@microsoft.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1908569
> 
> x86 Hyper-V used to essentially always overwrite the effective cache type
> of guest memory accesses to WB. This was problematic in cases where there
> is a physical device assigned to the VM, since that often requires that
> the VM should have control over cache types. Thus, on newer Hyper-V since
> 2018, Hyper-V always honors the VM's cache type, but unexpectedly Linux VM
> users start to complain that Linux VM's VRAM becomes very slow, and it
> turns out that Linux VM should not map the VRAM uncacheable by ioremap().
> Fix this slowness issue by using ioremap_cache().
> 
> On ARM64, ioremap_cache() is also required as the host also maps the VRAM
> cacheable, otherwise VM Connect can't display properly with ioremap() or
> ioremap_wc().
> 
> With this change, the VRAM on new Hyper-V is as fast as regular RAM, so
> it's no longer necessary to use the hacks we added to mitigate the
> slowness, i.e. we no longer need to allocate physical memory and use
> it to back up the VRAM in Generation-1 VM, and we also no longer need to
> allocate physical memory to back up the framebuffer in a Generation-2 VM
> and copy the framebuffer to the real VRAM. A further big change will
> address these for v5.11.
> 
> Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver")
> Tested-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> Link: https://lore.kernel.org/r/20201118000305.24797-1-decui@microsoft.com
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> (cherry picked from commit 5f1251a48c17b54939d7477305e39679a565382c)
> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
> ---
>  drivers/video/fbdev/hyperv_fb.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index fe4731f97df7..aad4eea522a9 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -705,7 +705,12 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
>  		goto err1;
>  	}
>  
> -	fb_virt = ioremap(par->mem->start, screen_fb_size);
> +	/*
> +	 * Map the VRAM cacheable for performance. This is also required for
> +	 * VM Connect to display properly for ARM64 Linux VM, as the host also
> +	 * maps the VRAM cacheable.
> +	 */
> +	fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
>  	if (!fb_virt)
>  		goto err2;
>  
> -- 
> 2.25.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
diff mbox series

Patch

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index fe4731f97df7..aad4eea522a9 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -705,7 +705,12 @@  static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
 		goto err1;
 	}
 
-	fb_virt = ioremap(par->mem->start, screen_fb_size);
+	/*
+	 * Map the VRAM cacheable for performance. This is also required for
+	 * VM Connect to display properly for ARM64 Linux VM, as the host also
+	 * maps the VRAM cacheable.
+	 */
+	fb_virt = ioremap_cache(par->mem->start, screen_fb_size);
 	if (!fb_virt)
 		goto err2;