[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201118093153.irs3i342nskkbuil@liuwe-devbox-debian-v2>
Date: Wed, 18 Nov 2020 09:31:53 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: Dexuan Cui <decui@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"b.zolnierkie@...sung.com" <b.zolnierkie@...sung.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Wei Hu <weh@...rosoft.com>
Subject: Re: [PATCH] video: hyperv_fb: Fix the cache type when mapping the
VRAM
On Wed, Nov 18, 2020 at 12:20:11AM +0000, Michael Kelley wrote:
> From: Dexuan Cui <decui@...rosoft.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@...il.com>
> > Signed-off-by: Dexuan Cui <decui@...rosoft.com>
> Reviewed-by: Michael Kelley <mikelley@...rosoft.com>
>
Applied to hyperv-fixes. Thanks.
Powered by blists - more mailing lists