On Wed, Nov 18, 2020 at 12:20:11AM +0000, Michael Kelley wrote:
> From: Dexuan Cui <decui@xxxxxxxxxxxxx> 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@xxxxxxxxx>
> > Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
> Reviewed-by: Michael Kelley <mikelley@xxxxxxxxxxxxx>
>
Applied to hyperv-fixes. Thanks.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
