Linux-fbdev Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
@ 2020-11-18  0:03 Dexuan Cui
  2020-11-18  0:20 ` Michael Kelley
  2020-11-18 21:10 ` Haiyang Zhang
  0 siblings, 2 replies; 4+ messages in thread
From: Dexuan Cui @ 2020-11-18  0:03 UTC (permalink / raw)
  To: kys, haiyangz, sthemmin, wei.liu, b.zolnierkie, linux-hyperv,
	dri-devel, linux-fbdev, linux-kernel, mikelley
  Cc: weh, Dexuan Cui

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>
---

Hi Wei Liu, can you please pick this up into the hyperv/linux.git tree's
hyperv-fixes branch? I really hope this patch can be in v5.10 since it
fixes a longstanding issue: https://github.com/LIS/lis-next/issues/655

 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 5bc86f481a78..c8b0ae676809 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1093,7 +1093,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.19.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
  2020-11-18  0:03 [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM Dexuan Cui
@ 2020-11-18  0:20 ` Michael Kelley
  2020-11-18  9:31   ` Wei Liu
  2020-11-18 21:10 ` Haiyang Zhang
  1 sibling, 1 reply; 4+ messages in thread
From: Michael Kelley @ 2020-11-18  0:20 UTC (permalink / raw)
  To: Dexuan Cui, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
	wei.liu, b.zolnierkie, linux-hyperv, dri-devel, linux-fbdev,
	linux-kernel
  Cc: Wei Hu

From: Dexuan Cui <decui@microsoft.com> Sent: Tuesday, November 17, 2020 4:03 PM
> 
> 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>
> ---
> 
> Hi Wei Liu, can you please pick this up into the hyperv/linux.git tree's
> hyperv-fixes branch? I really hope this patch can be in v5.10 since it
> fixes a longstanding issue: https://github.com/LIS/lis-next/issues/655
> 
>  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 5bc86f481a78..c8b0ae676809 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1093,7 +1093,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.19.1

Reviewed-by: Michael Kelley <mikelley@microsoft.com>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
  2020-11-18  0:20 ` Michael Kelley
@ 2020-11-18  9:31   ` Wei Liu
  0 siblings, 0 replies; 4+ messages in thread
From: Wei Liu @ 2020-11-18  9:31 UTC (permalink / raw)
  To: Michael Kelley
  Cc: Dexuan Cui, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
	wei.liu, b.zolnierkie, linux-hyperv, dri-devel, linux-fbdev,
	linux-kernel, Wei Hu

On Wed, Nov 18, 2020 at 12:20:11AM +0000, Michael Kelley wrote:
> From: Dexuan Cui <decui@microsoft.com> Sent: Tuesday, November 17, 2020 4:03 PM
> > 
> > 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>
> 

Applied to hyperv-fixes. Thanks.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM
  2020-11-18  0:03 [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM Dexuan Cui
  2020-11-18  0:20 ` Michael Kelley
@ 2020-11-18 21:10 ` Haiyang Zhang
  1 sibling, 0 replies; 4+ messages in thread
From: Haiyang Zhang @ 2020-11-18 21:10 UTC (permalink / raw)
  To: Dexuan Cui, KY Srinivasan, Stephen Hemminger, wei.liu,
	b.zolnierkie, linux-hyperv, dri-devel, linux-fbdev, linux-kernel,
	Michael Kelley
  Cc: Wei Hu



> -----Original Message-----
> From: Dexuan Cui <decui@microsoft.com>
> Sent: Tuesday, November 17, 2020 7:03 PM
> To: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; wei.liu@kernel.org;
> b.zolnierkie@samsung.com; linux-hyperv@vger.kernel.org; dri-
> devel@lists.freedesktop.org; linux-fbdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Michael Kelley <mikelley@microsoft.com>
> Cc: Wei Hu <weh@microsoft.com>; Dexuan Cui <decui@microsoft.com>
> Subject: [PATCH] video: hyperv_fb: Fix the cache type when mapping the
> VRAM
> 
> 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>
> ---
> 
> Hi Wei Liu, can you please pick this up into the hyperv/linux.git tree's hyperv-
> fixes branch? I really hope this patch can be in v5.10 since it fixes a
> longstanding issue:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FLIS%2Flis-
> next%2Fissues%2F655&amp;data=04%7C01%7Chaiyangz%40microsoft.com%
> 7C7e371bb6f79f41aae12208d88b556c85%7C72f988bf86f141af91ab2d7cd011d
> b47%7C1%7C0%7C637412546297591335%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&amp;sdata=StqnT%2Fx1XVoVWUZbJz5BNjaCIdtuNmSf2JoyLSt0c%2B
> Q%3D&amp;reserved=0
> 
>  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 5bc86f481a78..c8b0ae676809
> 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1093,7 +1093,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;

Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Thank you!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-18  0:03 [PATCH] video: hyperv_fb: Fix the cache type when mapping the VRAM Dexuan Cui
2020-11-18  0:20 ` Michael Kelley
2020-11-18  9:31   ` Wei Liu
2020-11-18 21:10 ` Haiyang Zhang

Linux-fbdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fbdev/0 linux-fbdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fbdev linux-fbdev/ https://lore.kernel.org/linux-fbdev \
		linux-fbdev@vger.kernel.org
	public-inbox-index linux-fbdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fbdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git