Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
On Wed, Oct 02, 2019 at 08:09:41AM +, Dexuan Cui wrote:
-Original Message-
From: Sasha Levin
Sent: Tuesday, October 1, 2019 11:48 AM
On Fri, Sep 20, 2019 at 05:26:34PM +, Michael Kelley wrote:
>From: Michael Kelley Sent: Wednesday,
September 18, 2019 2:48 PM
>> >
>> > Without deferred IO support, hyperv_fb driver informs the host to refresh
>> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
>> > is screen update or not. This patch supports deferred IO for screens in
>> > graphics mode and also enables the frame buffer on-demand refresh. The
>> > highest refresh rate is still set at 20Hz.
>> >
>> > Currently Hyper-V only takes a physical address from guest as the starting
>> > address of frame buffer. This implies the guest must allocate contiguous
>> > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
>> > accept address from MMIO region as frame buffer address. Due to these
>> > limitations on Hyper-V host, we keep a shadow copy of frame buffer
>> > in the guest. This means one more copy of the dirty rectangle inside
>> > guest when doing the on-demand refresh. This can be optimized in the
>> > future with help from host. For now the host performance gain from
deferred
>> > IO outweighs the shadow copy impact in the guest.
>> >
>> > Signed-off-by: Wei Hu
>
>Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
>driver should be ready. Both patches affect only the Hyper-V frame buffer
>driver so can go through the Hyper-V tree. Can you pick these up? Thx.
I can't get this to apply anywhere, what tree is it based on?
--
Thanks,
Sasha
Hi Sasha,
Today's hyperv/linux.git's hyperv-next branch's top commit is
48b72a2697d5 ("hv_netvsc: Add the support of hibernation").
Please pick up two patches from Wei Hu:
#1: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V
host
#2: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame
buffer driver
Ah, I guess I was missing the first one. I've queued both for
hyperv-next, thanks!
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, October 1, 2019 11:48 AM
>
> On Fri, Sep 20, 2019 at 05:26:34PM +, Michael Kelley wrote:
> >From: Michael Kelley Sent: Wednesday,
> September 18, 2019 2:48 PM
> >> >
> >> > Without deferred IO support, hyperv_fb driver informs the host to refresh
> >> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter
> >> > there
> >> > is screen update or not. This patch supports deferred IO for screens in
> >> > graphics mode and also enables the frame buffer on-demand refresh. The
> >> > highest refresh rate is still set at 20Hz.
> >> >
> >> > Currently Hyper-V only takes a physical address from guest as the
> >> > starting
> >> > address of frame buffer. This implies the guest must allocate contiguous
> >> > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
> >> > accept address from MMIO region as frame buffer address. Due to these
> >> > limitations on Hyper-V host, we keep a shadow copy of frame buffer
> >> > in the guest. This means one more copy of the dirty rectangle inside
> >> > guest when doing the on-demand refresh. This can be optimized in the
> >> > future with help from host. For now the host performance gain from
> deferred
> >> > IO outweighs the shadow copy impact in the guest.
> >> >
> >> > Signed-off-by: Wei Hu
> >
> >Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
> >driver should be ready. Both patches affect only the Hyper-V frame buffer
> >driver so can go through the Hyper-V tree. Can you pick these up? Thx.
>
> I can't get this to apply anywhere, what tree is it based on?
>
> --
> Thanks,
> Sasha
Hi Sasha,
Today's hyperv/linux.git's hyperv-next branch's top commit is
48b72a2697d5 ("hv_netvsc: Add the support of hibernation").
Please pick up two patches from Wei Hu:
#1: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V
host
#2: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame
buffer driver
I can apply the 2 patches on the hyperv-next branch (the top commit is
48b72a2697d5):
[decui@localhost linux]$ patch -p1 < 1.diff
patching file drivers/video/fbdev/hyperv_fb.c
Hunk #2 succeeded at 53 (offset 1 line).
Hunk #3 succeeded at 95 (offset 1 line).
Hunk #4 succeeded at 124 (offset 1 line).
Hunk #5 succeeded at 222 (offset 1 line).
Hunk #6 succeeded at 262 (offset 2 lines).
Hunk #7 succeeded at 394 (offset 2 lines).
Hunk #8 succeeded at 441 (offset 2 lines).
Hunk #9 succeeded at 480 (offset 2 lines).
Hunk #10 succeeded at 558 (offset 2 lines).
Hunk #11 succeeded at 590 (offset 2 lines).
Hunk #12 succeeded at 785 (offset 2 lines).
Hunk #13 succeeded at 823 (offset 2 lines).
[decui@localhost linux]$ patch -p1 < 2.diff
patching file drivers/video/fbdev/Kconfig
Hunk #1 succeeded at 2214 (offset -27 lines).
patching file drivers/video/fbdev/hyperv_fb.c
Hunk #1 succeeded at 238 (offset 1 line).
Hunk #2 succeeded at 259 (offset 2 lines).
Hunk #3 succeeded at 277 (offset 2 lines).
Hunk #4 succeeded at 364 (offset 2 lines).
Hunk #5 succeeded at 692 (offset 2 lines).
Hunk #6 succeeded at 702 (offset 2 lines).
Hunk #7 succeeded at 719 (offset 2 lines).
Hunk #8 succeeded at 801 (offset 2 lines).
Hunk #9 succeeded at 863 (offset 2 lines).
Hunk #10 succeeded at 876 (offset 2 lines).
Hunk #11 succeeded at 889 (offset 2 lines).
Hunk #12 succeeded at 951 (offset 2 lines).
Hunk #13 succeeded at 988 (offset 2 lines).
Hunk #14 succeeded at 1007 (offset 2 lines).
Hunk #15 succeeded at 1041 (offset 2 lines).
Thanks,
-- Dexuan
Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
On Fri, Sep 20, 2019 at 05:26:34PM +, Michael Kelley wrote: From: Michael Kelley Sent: Wednesday, September 18, 2019 2:48 PM > > Without deferred IO support, hyperv_fb driver informs the host to refresh > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there > is screen update or not. This patch supports deferred IO for screens in > graphics mode and also enables the frame buffer on-demand refresh. The > highest refresh rate is still set at 20Hz. > > Currently Hyper-V only takes a physical address from guest as the starting > address of frame buffer. This implies the guest must allocate contiguous > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only > accept address from MMIO region as frame buffer address. Due to these > limitations on Hyper-V host, we keep a shadow copy of frame buffer > in the guest. This means one more copy of the dirty rectangle inside > guest when doing the on-demand refresh. This can be optimized in the > future with help from host. For now the host performance gain from deferred > IO outweighs the shadow copy impact in the guest. > > Signed-off-by: Wei Hu Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer driver should be ready. Both patches affect only the Hyper-V frame buffer driver so can go through the Hyper-V tree. Can you pick these up? Thx. I can't get this to apply anywhere, what tree is it based on? -- Thanks, Sasha
RE: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Michael Kelley Sent: Wednesday, September 18, 2019 2:48 PM > > > > Without deferred IO support, hyperv_fb driver informs the host to refresh > > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there > > is screen update or not. This patch supports deferred IO for screens in > > graphics mode and also enables the frame buffer on-demand refresh. The > > highest refresh rate is still set at 20Hz. > > > > Currently Hyper-V only takes a physical address from guest as the starting > > address of frame buffer. This implies the guest must allocate contiguous > > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only > > accept address from MMIO region as frame buffer address. Due to these > > limitations on Hyper-V host, we keep a shadow copy of frame buffer > > in the guest. This means one more copy of the dirty rectangle inside > > guest when doing the on-demand refresh. This can be optimized in the > > future with help from host. For now the host performance gain from deferred > > IO outweighs the shadow copy impact in the guest. > > > > Signed-off-by: Wei Hu Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer driver should be ready. Both patches affect only the Hyper-V frame buffer driver so can go through the Hyper-V tree. Can you pick these up? Thx. Michael
RE: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Wei Hu Sent: Tuesday, September 17, 2019 11:03 PM > > Without deferred IO support, hyperv_fb driver informs the host to refresh > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there > is screen update or not. This patch supports deferred IO for screens in > graphics mode and also enables the frame buffer on-demand refresh. The > highest refresh rate is still set at 20Hz. > > Currently Hyper-V only takes a physical address from guest as the starting > address of frame buffer. This implies the guest must allocate contiguous > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only > accept address from MMIO region as frame buffer address. Due to these > limitations on Hyper-V host, we keep a shadow copy of frame buffer > in the guest. This means one more copy of the dirty rectangle inside > guest when doing the on-demand refresh. This can be optimized in the > future with help from host. For now the host performance gain from deferred > IO outweighs the shadow copy impact in the guest. > > Signed-off-by: Wei Hu > --- > v2: Incorporated review comments from Michael Kelley > - Increased dirty rectangle by one row in deferred IO case when sending > to Hyper-V. > - Corrected the dirty rectangle size in the text mode. > - Added more comments. > - Other minor code cleanups. > > v3: Incorporated more review comments > - Removed a few unnecessary variable tests > > v4: Incorporated test and review feedback from Dexuan Cui > - Not disable interrupt while acquiring docopy_lock in > hvfb_update_work(). This avoids significant bootup delay in > large vCPU count VMs. > > v5: Completely remove the unnecessary docopy_lock after discussing > with Dexuan Cui. > > v6: Do not request host refresh when the VM guest screen is > closed or minimized. > > drivers/video/fbdev/Kconfig | 1 + > drivers/video/fbdev/hyperv_fb.c | 210 > 2 files changed, 190 insertions(+), 21 deletions(-) > Reviewed-by: Michael Kelley
RE: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
> From: Wei Hu > Sent: Tuesday, September 17, 2019 11:03 PM > [...] > --- > v6: Do not request host refresh when the VM guest screen is > closed or minimized. Looks good to me. Thanks! Reviewed-by: Dexuan Cui
