From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Robert Beckett" <bob.beckett@collabora.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>,
"Hildebrand, Stewart" <Stewart.Hildebrand@amd.com>,
"Xenia Ragiadakou" <burzalodowa@gmail.com>,
"Huang, Honglei1" <Honglei1.Huang@amd.com>,
"Zhang, Julia" <Julia.Zhang@amd.com>,
"Huang, Ray" <Ray.Huang@amd.com>,
"Chen, Jiqian" <Jiqian.Chen@amd.com>
Subject: [virtio-comment] Re: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3
Date: Tue, 19 Sep 2023 12:04:24 +0000 [thread overview]
Message-ID: <BL1PR12MB5849327D32AA77C793E8E625E7FAA@BL1PR12MB5849.namprd12.prod.outlook.com> (raw)
In-Reply-To: <FR0P281MB286152665C939C9CE291CE63BCF2A@FR0P281MB2861.DEUP281.PROD.OUTLOOK.COM>
Hi Mikhail Golubev-Ciuchea,
I have improved this implementation to the virtio pci level. Could you please try my patches and see if them are useful in your scene?
My new series:
V5 of Qemu patch:
https://lore.kernel.org/qemu-devel/20230919110225.2282914-1-Jiqian.Chen@amd.com/T/#t
V5 of kernel patch:
https://lore.kernel.org/lkml/20230919104607.2282248-1-Jiqian.Chen@amd.com/T/#t
V5 of virtio-spec patch:
https://lists.oasis-open.org/archives/virtio-comment/202309/msg00245.html
On 2023/9/12 00:33, Mikhail Golubev-Ciuchea wrote:
> Hi Jiqian,
>
> Thanks for the proposal.
>
> Some time ago I was working on the same issue with suspending the gpu device
> (on arm). Additionally, I had troubles with virtio-video device as well, see
> https://lore.kernel.org/lkml/20211215172739.GA77225@opensynergy.com/T/ for
> details.
>
> In your case, the
> VIRTIO_GPU_FREEZE_MODE_FREEZE_S3/VIRTIO_GPU_FREEZE_MODE_UNFREEZE do influence
> how reset is being handled by Qemu, is this correct? Since multiple devices
> can benefit from the same mechanism, would it be possible to: a) have a more
> generic, non ACPI-based name, b) make the feature generic, applicable to other
> devices as well?
>
>
> Best wishes,
> Mikhail Golubev-Ciuchea
>
>
>
> --
>
> Mikhail Golubev-Ciuchea
>
>
> OpenSynergy GmbH
>
> Rotherstr. 20, 10245 Berlin
>
> Telefon: +49 (30) 60 98 54 0 - 903
>
> EMail: mikhail.golubev@opensynergy.com
>
> www.opensynergy.com
>
> Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
>
> Geschäftsführer/Managing Director: Regis Adjamah
>
>
> ________________________________________
> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> on behalf of Jiqian Chen <Jiqian.Chen@amd.com>
> Sent: Monday, September 11, 2023 12:04 PM
> To: Gerd Hoffmann; Marc-André Lureau; Robert Beckett; virtio-comment@lists.oasis-open.org; virtio-dev@lists.oasis-open.org
> Cc: qemu-devel@nongnu.org; linux-kernel@vger.kernel.org; Stefano Stabellini; Roger Pau Monné; Alex Deucher; Christian Koenig; Stewart Hildebrand; Xenia Ragiadakou; Honglei Huang; Julia Zhang; Huang Rui; Jiqian Chen
> Subject: [virtio-dev] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: Add new feature flag VIRTIO_GPU_F_FREEZE_S3
>
> When we suspend/resume guest on Xen, the display can't come back.
> This is because when guest suspended, it called into Qemu. Then
> Qemu destroyed all resources which is used for display. So that
> guest's display can't come back to the time when it was suspended.
>
> To solve above problem, I added a new mechanism that when guest is
> suspending, it will notify Qemu, and then Qemu will not destroy
> resourcesi which are created by using commands
> VIRTIO_GPU_CMD_RESOURCE_CREATE_*.
>
> Due to that mechanism needs cooperation between guest and host,
> I need to add a new feature flag, so that guest and host can
> negotiate whenever freeze_S3 is supported or not.
>
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
> device-types/gpu/description.tex | 42 ++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
> index 4435248..1a137e7 100644
> --- a/device-types/gpu/description.tex
> +++ b/device-types/gpu/description.tex
> @@ -37,6 +37,8 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
> resources is supported.
> \item[VIRTIO_GPU_F_CONTEXT_INIT (4)] multiple context types and
> synchronization timelines supported. Requires VIRTIO_GPU_F_VIRGL.
> +\item[VIRTIO_GPU_F_FREEZE_S3 (5)] freezing virtio-gpu and keeping resources
> + alive is supported.
> \end{description}
>
> \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
> @@ -228,6 +230,9 @@ \subsubsection{Device Operation: Request header}\label{sec:Device Types / GPU De
> VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
> VIRTIO_GPU_CMD_MOVE_CURSOR,
>
> + /* freeze mode */
> + VIRTIO_GPU_CMD_SET_FREEZE_MODE = 0x0400,
> +
> /* success responses */
> VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
> VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
> @@ -838,6 +843,43 @@ \subsubsection{Device Operation: cursorq}\label{sec:Device Types / GPU Device /
>
> \end{description}
>
> +\subsubsection{Device Operation: freeze_mode}\label{sec:Device Types / GPU Device / Device Operation / Device Operation: freeze_mode}
> +
> +\begin{lstlisting}
> +typedef enum {
> + VIRTIO_GPU_FREEZE_MODE_UNFREEZE = 0,
> + VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 = 3,
> +} virtio_gpu_freeze_mode_t;
> +
> +struct virtio_gpu_set_freeze_mode {
> + struct virtio_gpu_ctrl_hdr hdr;
> + virtio_gpu_freeze_mode_t freeze_mode;
> +};
> +\end{lstlisting}
> +
> +\begin{description}
> +
> +\item[VIRTIO_GPU_CMD_SET_FREEZE_MODE]
> +Notify freeze mode through controlq.
> +Request data is \field{struct virtio_gpu_set_freeze_mode}.
> +Response type is VIRTIO_GPU_RESP_OK_NODATA.
> +
> +This is added for S3 function in guest with virtio-gpu. When guest does
> +S3, let it notify QEMU that virtio-gpu is in what freeze mode in
> +\field{freeze_mode}. VIRTIO_GPU_FREEZE_MODE_FREEZE_S3 means guest is
> +doing S3 and virtio-gpu will be freezed, VIRTIO_GPU_FREEZE_MODE_UNFREEZE
> +means virtio-gpu can be used as usual. When virtio-gpu is freezed, QEMU
> +will not destroy resources which are created by using commands
> +VIRTIO_GPU_CMD_RESOURCE_CREATE_*, so that guest can use those resources
> +to resume display.
> +
> +Note: this change is not enough to solve the problems of S4 function.
> +QEMU may lose resources after hibernation. It needs more research and
> +development. If S4 is supported in the future, it may need another
> +feature flag here.
> +
> +\end{description}
> +
> \subsection{VGA Compatibility}\label{sec:Device Types / GPU Device / VGA Compatibility}
>
> Applies to Virtio Over PCI only. The GPU device can come with and
> --
> 2.34.1
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
--
Best regards,
Jiqian Chen.
prev parent reply other threads:[~2023-09-19 12:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 10:04 [virtio-comment] [RESEND VIRTIO GPU PATCH v3 0/1] Add new feature flag VIRTIO_GPU_F_FREEZE_S3 Jiqian Chen
2023-09-11 10:04 ` [virtio-comment] [RESEND VIRTIO GPU PATCH v3 1/1] virtio-gpu: " Jiqian Chen
2023-09-11 16:33 ` [virtio-comment] Re: [virtio-dev] " Mikhail Golubev-Ciuchea
2023-09-12 10:41 ` Chen, Jiqian
2023-09-19 12:04 ` Chen, Jiqian [this message]
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=BL1PR12MB5849327D32AA77C793E8E625E7FAA@BL1PR12MB5849.namprd12.prod.outlook.com \
--to=jiqian.chen@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Honglei1.Huang@amd.com \
--cc=Julia.Zhang@amd.com \
--cc=Mikhail.Golubev-Ciuchea@opensynergy.com \
--cc=Ray.Huang@amd.com \
--cc=Stewart.Hildebrand@amd.com \
--cc=bob.beckett@collabora.com \
--cc=burzalodowa@gmail.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcandre.lureau@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).