From: Sasha Levin <sashal@kernel.org>
To: Michael Kelley <mikelley@microsoft.com>
Cc: "info@metux.net" <info@metux.net>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
Wei Hu <weh@microsoft.com>, "shc_work@mail.ru" <shc_work@mail.ru>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Haiyang Zhang <haiyangz@microsoft.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
Dexuan Cui <decui@microsoft.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"baijiaju1990@gmail.com" <baijiaju1990@gmail.com>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
Stephen Hemminger <sthemmin@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
"lee.jones@linaro.org" <lee.jones@linaro.org>
Subject: Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Date: Tue, 01 Oct 2019 18:48:28 +0000 [thread overview]
Message-ID: <20191001184828.GF8171@sasha-vm> (raw)
In-Reply-To: <DM5PR21MB01375E8543451D4550D622CDD7880@DM5PR21MB0137.namprd21.prod.outlook.com>
On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
>From: Michael Kelley <mikelley@microsoft.com> 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 <weh@microsoft.com>
>
>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
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: Michael Kelley <mikelley@microsoft.com>
Cc: Wei Hu <weh@microsoft.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"shc_work@mail.ru" <shc_work@mail.ru>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"baijiaju1990@gmail.com" <baijiaju1990@gmail.com>,
"info@metux.net" <info@metux.net>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stephen Hemminger <sthemmin@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Date: Tue, 1 Oct 2019 14:48:28 -0400 [thread overview]
Message-ID: <20191001184828.GF8171@sasha-vm> (raw)
In-Reply-To: <DM5PR21MB01375E8543451D4550D622CDD7880@DM5PR21MB0137.namprd21.prod.outlook.com>
On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
>From: Michael Kelley <mikelley@microsoft.com> 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 <weh@microsoft.com>
>
>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
WARNING: multiple messages have this Message-ID (diff)
From: Sasha Levin <sashal@kernel.org>
To: Michael Kelley <mikelley@microsoft.com>
Cc: "info@metux.net" <info@metux.net>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
Wei Hu <weh@microsoft.com>, "shc_work@mail.ru" <shc_work@mail.ru>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Haiyang Zhang <haiyangz@microsoft.com>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
Dexuan Cui <decui@microsoft.com>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"baijiaju1990@gmail.com" <baijiaju1990@gmail.com>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
Stephen Hemminger <sthemmin@microsoft.com>,
KY Srinivasan <kys@microsoft.com>,
"lee.jones@linaro.org" <lee.jones@linaro.org>
Subject: Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Date: Tue, 1 Oct 2019 14:48:28 -0400 [thread overview]
Message-ID: <20191001184828.GF8171@sasha-vm> (raw)
In-Reply-To: <DM5PR21MB01375E8543451D4550D622CDD7880@DM5PR21MB0137.namprd21.prod.outlook.com>
On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
>From: Michael Kelley <mikelley@microsoft.com> 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 <weh@microsoft.com>
>
>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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-10-01 18:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 6:03 [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver Wei Hu
2019-09-18 6:03 ` Wei Hu
2019-09-18 16:45 ` Dexuan Cui
2019-09-18 16:45 ` Dexuan Cui
2019-09-18 21:48 ` Michael Kelley
2019-09-18 21:48 ` Michael Kelley
2019-09-20 17:26 ` Michael Kelley
2019-09-20 17:26 ` Michael Kelley
2019-10-01 18:48 ` Sasha Levin [this message]
2019-10-01 18:48 ` Sasha Levin
2019-10-01 18:48 ` Sasha Levin
2019-10-02 8:09 ` Dexuan Cui
2019-10-02 8:09 ` Dexuan Cui
2019-10-02 12:40 ` Sasha Levin
2019-10-02 12:40 ` Sasha Levin
2019-10-02 12:40 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191001184828.GF8171@sasha-vm \
--to=sashal@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=baijiaju1990@gmail.com \
--cc=decui@microsoft.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=info@metux.net \
--cc=kys@microsoft.com \
--cc=lee.jones@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikelley@microsoft.com \
--cc=rdunlap@infradead.org \
--cc=shc_work@mail.ru \
--cc=sthemmin@microsoft.com \
--cc=weh@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.