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