All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"David Airlie" <airlied@redhat.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Robert Beckett" <bob.beckett@collabora.com>,
	"Mikhail Golubev-Ciuchea"
	<Mikhail.Golubev-Ciuchea@opensynergy.com>,
	"Parav Pandit" <parav@nvidia.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-kernel@vger.kernel.org,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Alex Deucher" <Alexander.Deucher@amd.com>,
	"Christian Koenig" <Christian.Koenig@amd.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Honglei Huang" <Honglei1.Huang@amd.com>,
	"Julia Zhang" <Julia.Zhang@amd.com>,
	"Huang Rui" <Ray.Huang@amd.com>
Subject: [virtio-comment] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg
Date: Tue, 19 Sep 2023 08:31:11 -0400	[thread overview]
Message-ID: <20230919082802-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230919114242.2283646-2-Jiqian.Chen@amd.com>

On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
> When guest vm does S3, Qemu will reset and clear some things of virtio
> devices, but guest can't aware that, so that may cause some problems.
> For excample, Qemu calls virtio_reset->virtio_gpu_gl_reset when guest
> resume, that function will destroy render resources of virtio-gpu. As
> a result, after guest resume, the display can't come back and we only
> saw a black screen. Due to guest can't re-create all the resources, so
> we need to let Qemu not to destroy them when S3.
> 
> For above purpose, we need a mechanism that allows guests and QEMU to
> negotiate their reset behavior. So this patch add a new parameter
> named freeze_mode to struct virtio_pci_common_cfg. And when guest
> suspends, it can write freeze_mode to be FREEZE_S3, and then virtio
> devices can change their reset behavior on Qemu side according to
> freeze_mode. What's more, freeze_mode can be used for all virtio
> devices to affect the behavior of Qemu, not just virtio gpu device.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
>  transport-pci.tex | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719..2543536 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -319,6 +319,7 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>          le64 queue_desc;                /* read-write */
>          le64 queue_driver;              /* read-write */
>          le64 queue_device;              /* read-write */
> +        le16 freeze_mode;               /* read-write */
>          le16 queue_notif_config_data;   /* read-only for driver */
>          le16 queue_reset;               /* read-write */
>

we can't add fields in the middle of the structure like this -
offset of queue_notif_config_data and queue_reset changes.

  
> @@ -393,6 +394,12 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>  \item[\field{queue_device}]
>          The driver writes the physical address of Device Area here.  See section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues}.
>  
> +\item[\field{freeze_mode}]
> +        The driver writes this to set the freeze mode of virtio pci.
> +        VIRTIO_PCI_FREEZE_MODE_UNFREEZE - virtio-pci is running;
> +        VIRTIO_PCI_FREEZE_MODE_FREEZE_S3 - guest vm is doing S3, and virtio-pci enters S3 suspension;
> +        Other values are reserved for future use, like S4, etc.
> +

we need to specify these values then.

we also need
- feature bit to detect support for S3
- conformance statements documenting behavious under S3


>  \item[\field{queue_notif_config_data}]
>          This field exists only if VIRTIO_F_NOTIF_CONFIG_DATA has been negotiated.
>          The driver will use this value when driver sends available buffer
> -- 
> 2.34.1


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"David Airlie" <airlied@redhat.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Robert Beckett" <bob.beckett@collabora.com>,
	"Mikhail Golubev-Ciuchea"
	<Mikhail.Golubev-Ciuchea@opensynergy.com>,
	"Parav Pandit" <parav@nvidia.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-kernel@vger.kernel.org,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Alex Deucher" <Alexander.Deucher@amd.com>,
	"Christian Koenig" <Christian.Koenig@amd.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Honglei Huang" <Honglei1.Huang@amd.com>,
	"Julia Zhang" <Julia.Zhang@amd.com>,
	"Huang Rui" <Ray.Huang@amd.com>
Subject: [virtio-dev] Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg
Date: Tue, 19 Sep 2023 08:31:11 -0400	[thread overview]
Message-ID: <20230919082802-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230919114242.2283646-2-Jiqian.Chen@amd.com>

On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
> When guest vm does S3, Qemu will reset and clear some things of virtio
> devices, but guest can't aware that, so that may cause some problems.
> For excample, Qemu calls virtio_reset->virtio_gpu_gl_reset when guest
> resume, that function will destroy render resources of virtio-gpu. As
> a result, after guest resume, the display can't come back and we only
> saw a black screen. Due to guest can't re-create all the resources, so
> we need to let Qemu not to destroy them when S3.
> 
> For above purpose, we need a mechanism that allows guests and QEMU to
> negotiate their reset behavior. So this patch add a new parameter
> named freeze_mode to struct virtio_pci_common_cfg. And when guest
> suspends, it can write freeze_mode to be FREEZE_S3, and then virtio
> devices can change their reset behavior on Qemu side according to
> freeze_mode. What's more, freeze_mode can be used for all virtio
> devices to affect the behavior of Qemu, not just virtio gpu device.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
>  transport-pci.tex | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719..2543536 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -319,6 +319,7 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>          le64 queue_desc;                /* read-write */
>          le64 queue_driver;              /* read-write */
>          le64 queue_device;              /* read-write */
> +        le16 freeze_mode;               /* read-write */
>          le16 queue_notif_config_data;   /* read-only for driver */
>          le16 queue_reset;               /* read-write */
>

we can't add fields in the middle of the structure like this -
offset of queue_notif_config_data and queue_reset changes.

  
> @@ -393,6 +394,12 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>  \item[\field{queue_device}]
>          The driver writes the physical address of Device Area here.  See section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues}.
>  
> +\item[\field{freeze_mode}]
> +        The driver writes this to set the freeze mode of virtio pci.
> +        VIRTIO_PCI_FREEZE_MODE_UNFREEZE - virtio-pci is running;
> +        VIRTIO_PCI_FREEZE_MODE_FREEZE_S3 - guest vm is doing S3, and virtio-pci enters S3 suspension;
> +        Other values are reserved for future use, like S4, etc.
> +

we need to specify these values then.

we also need
- feature bit to detect support for S3
- conformance statements documenting behavious under S3


>  \item[\field{queue_notif_config_data}]
>          This field exists only if VIRTIO_F_NOTIF_CONFIG_DATA has been negotiated.
>          The driver will use this value when driver sends available buffer
> -- 
> 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


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiqian Chen <Jiqian.Chen@amd.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"David Airlie" <airlied@redhat.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Robert Beckett" <bob.beckett@collabora.com>,
	"Mikhail Golubev-Ciuchea"
	<Mikhail.Golubev-Ciuchea@opensynergy.com>,
	"Parav Pandit" <parav@nvidia.com>,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	linux-kernel@vger.kernel.org,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Alex Deucher" <Alexander.Deucher@amd.com>,
	"Christian Koenig" <Christian.Koenig@amd.com>,
	"Stewart Hildebrand" <Stewart.Hildebrand@amd.com>,
	"Xenia Ragiadakou" <burzalodowa@gmail.com>,
	"Honglei Huang" <Honglei1.Huang@amd.com>,
	"Julia Zhang" <Julia.Zhang@amd.com>,
	"Huang Rui" <Ray.Huang@amd.com>
Subject: Re: [VIRTIO PCI PATCH v5 1/1] transport-pci: Add freeze_mode to virtio_pci_common_cfg
Date: Tue, 19 Sep 2023 08:31:11 -0400	[thread overview]
Message-ID: <20230919082802-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230919114242.2283646-2-Jiqian.Chen@amd.com>

On Tue, Sep 19, 2023 at 07:42:42PM +0800, Jiqian Chen wrote:
> When guest vm does S3, Qemu will reset and clear some things of virtio
> devices, but guest can't aware that, so that may cause some problems.
> For excample, Qemu calls virtio_reset->virtio_gpu_gl_reset when guest
> resume, that function will destroy render resources of virtio-gpu. As
> a result, after guest resume, the display can't come back and we only
> saw a black screen. Due to guest can't re-create all the resources, so
> we need to let Qemu not to destroy them when S3.
> 
> For above purpose, we need a mechanism that allows guests and QEMU to
> negotiate their reset behavior. So this patch add a new parameter
> named freeze_mode to struct virtio_pci_common_cfg. And when guest
> suspends, it can write freeze_mode to be FREEZE_S3, and then virtio
> devices can change their reset behavior on Qemu side according to
> freeze_mode. What's more, freeze_mode can be used for all virtio
> devices to affect the behavior of Qemu, not just virtio gpu device.
> 
> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
> ---
>  transport-pci.tex | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/transport-pci.tex b/transport-pci.tex
> index a5c6719..2543536 100644
> --- a/transport-pci.tex
> +++ b/transport-pci.tex
> @@ -319,6 +319,7 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>          le64 queue_desc;                /* read-write */
>          le64 queue_driver;              /* read-write */
>          le64 queue_device;              /* read-write */
> +        le16 freeze_mode;               /* read-write */
>          le16 queue_notif_config_data;   /* read-only for driver */
>          le16 queue_reset;               /* read-write */
>

we can't add fields in the middle of the structure like this -
offset of queue_notif_config_data and queue_reset changes.

  
> @@ -393,6 +394,12 @@ \subsubsection{Common configuration structure layout}\label{sec:Virtio Transport
>  \item[\field{queue_device}]
>          The driver writes the physical address of Device Area here.  See section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues}.
>  
> +\item[\field{freeze_mode}]
> +        The driver writes this to set the freeze mode of virtio pci.
> +        VIRTIO_PCI_FREEZE_MODE_UNFREEZE - virtio-pci is running;
> +        VIRTIO_PCI_FREEZE_MODE_FREEZE_S3 - guest vm is doing S3, and virtio-pci enters S3 suspension;
> +        Other values are reserved for future use, like S4, etc.
> +

we need to specify these values then.

we also need
- feature bit to detect support for S3
- conformance statements documenting behavious under S3


>  \item[\field{queue_notif_config_data}]
>          This field exists only if VIRTIO_F_NOTIF_CONFIG_DATA has been negotiated.
>          The driver will use this value when driver sends available buffer
> -- 
> 2.34.1


  parent reply	other threads:[~2023-09-19 12:31 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 11:42 [virtio-comment] [VIRTIO PCI PATCH v5 0/1] Add freeze_mode to virtio_pci_common_cfg Jiqian Chen
2023-09-19 11:42 ` Jiqian Chen
2023-09-19 11:42 ` [virtio-dev] " Jiqian Chen
2023-09-19 11:42 ` [virtio-comment] [VIRTIO PCI PATCH v5 1/1] transport-pci: " Jiqian Chen
2023-09-19 11:42   ` Jiqian Chen
2023-09-19 11:42   ` [virtio-dev] " Jiqian Chen
2023-09-19 12:10   ` [virtio-comment] " Parav Pandit
2023-09-19 12:10     ` Parav Pandit
2023-09-19 12:10     ` [virtio-dev] " Parav Pandit
2023-09-19 14:09     ` [virtio-comment] " Michael S. Tsirkin
2023-09-19 14:09       ` Michael S. Tsirkin
2023-09-19 14:09       ` [virtio-dev] " Michael S. Tsirkin
2023-09-20  3:57     ` [virtio-comment] Re: [virtio-dev] " Chen, Jiqian
2023-09-20  3:57       ` Chen, Jiqian
2023-09-20  4:10       ` [virtio-comment] " Parav Pandit
2023-09-20  4:10         ` Parav Pandit
2023-09-19 12:31   ` Michael S. Tsirkin [this message]
2023-09-19 12:31     ` Michael S. Tsirkin
2023-09-19 12:31     ` [virtio-dev] " Michael S. Tsirkin
2023-09-20  4:56     ` [virtio-comment] " Chen, Jiqian
2023-09-20  4:56       ` Chen, Jiqian
2023-09-20  4:56       ` [virtio-dev] " Chen, Jiqian
2023-09-20  5:59     ` [virtio-comment] " Zhu, Lingshan
2023-09-20  5:59       ` Zhu, Lingshan
2023-09-20  5:59       ` [virtio-dev] " Zhu, Lingshan
2023-09-20  6:33       ` [virtio-comment] " Chen, Jiqian
2023-09-20  6:33         ` Chen, Jiqian
2023-09-20  6:58         ` [virtio-comment] " Parav Pandit
2023-09-20  6:58           ` Parav Pandit
2023-09-20  7:06           ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:06             ` Zhu, Lingshan
2023-09-20  7:06             ` Zhu, Lingshan
2023-09-20  7:10             ` [virtio-comment] " Parav Pandit
2023-09-20  7:10               ` Parav Pandit
2023-09-20  7:27               ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:27                 ` Zhu, Lingshan
2023-09-20  7:27                 ` Zhu, Lingshan
2023-09-20  7:32                 ` [virtio-comment] " Parav Pandit
2023-09-20  7:32                   ` Parav Pandit
2023-09-20  7:45                   ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:45                     ` Zhu, Lingshan
2023-09-20  7:45                     ` Zhu, Lingshan
2023-09-20  7:47                     ` [virtio-comment] " Parav Pandit
2023-09-20  7:47                       ` Parav Pandit
2023-09-20  7:24             ` [virtio-comment] " Chen, Jiqian
2023-09-20  7:24               ` Chen, Jiqian
2023-09-20  7:30               ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:30                 ` Zhu, Lingshan
2023-09-20  7:30                 ` Zhu, Lingshan
2023-09-20  7:35                 ` [virtio-comment] " Parav Pandit
2023-09-20  7:35                   ` Parav Pandit
2023-09-20  7:47                   ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:47                     ` Zhu, Lingshan
2023-09-20  7:47                     ` Zhu, Lingshan
2023-09-20  7:51                     ` [virtio-comment] " Parav Pandit
2023-09-20  7:51                       ` Parav Pandit
2023-09-20  7:55                       ` [virtio-comment] " Zhu, Lingshan
2023-09-20  7:55                         ` Zhu, Lingshan
2023-09-20  7:55                         ` Zhu, Lingshan
2023-09-20  7:53                     ` [virtio-comment] " Chen, Jiqian
2023-09-20  7:53                       ` Chen, Jiqian
2023-09-20  7:56                       ` [virtio-comment] " Parav Pandit
2023-09-20  7:56                         ` Parav Pandit
2023-09-20  8:18                         ` [virtio-comment] " Chen, Jiqian
2023-09-20  8:18                           ` [virtio-dev] " Chen, Jiqian
2023-09-20  6:58         ` [virtio-comment] " Zhu, Lingshan
2023-09-20  6:58           ` Zhu, Lingshan
2023-09-20  6:58           ` Zhu, Lingshan
2023-09-20  7:17           ` [virtio-comment] " Chen, Jiqian
2023-09-20  7:17             ` [virtio-dev] " Chen, Jiqian
2023-09-20  7:42             ` Zhu, Lingshan
2023-09-20  7:42               ` Zhu, Lingshan
2023-09-20  7:42               ` [virtio-dev] " Zhu, Lingshan
2023-09-21  4:22   ` Jason Wang
2023-09-21  4:22     ` Jason Wang
2023-09-21  4:22     ` [virtio-dev] " Jason Wang
2023-09-21  6:28     ` [virtio-comment] " Chen, Jiqian
2023-09-21  6:28       ` Chen, Jiqian
2023-09-22  3:17       ` [virtio-comment] " Jason Wang
2023-09-22  3:17         ` Jason Wang
2023-09-22  3:17         ` Jason Wang
2023-09-22  8:07         ` [virtio-comment] " Chen, Jiqian
2023-09-22  8:07           ` Chen, Jiqian
2023-09-25  2:52           ` [virtio-comment] " Jason Wang
2023-09-25  2:52             ` Jason Wang
2023-09-26  2:23             ` [virtio-comment] " Chen, Jiqian
2023-09-26  2:23               ` Chen, Jiqian
2023-09-26  2:51               ` [virtio-comment] " Jason Wang
2023-09-26  2:51                 ` Jason Wang
2023-09-26 11:00                 ` [virtio-comment] " Chen, Jiqian
2023-09-26 11:00                   ` Chen, Jiqian
2023-09-26 11:09                   ` [virtio-comment] " Michael S. Tsirkin
2023-09-26 11:09                     ` Michael S. Tsirkin
2023-09-27  9:00                     ` [virtio-comment] " Chen, Jiqian
2023-09-27  9:00                       ` Chen, Jiqian
2023-09-26 11:37                   ` [virtio-comment] " Parav Pandit
2023-09-26 11:37                     ` Parav Pandit
2023-09-26 11:57                     ` [virtio-comment] " Michael S. Tsirkin
2023-09-26 11:57                       ` Michael S. Tsirkin
2023-09-27 10:18                       ` [virtio-comment] " Parav Pandit
2023-09-27 10:18                         ` Parav Pandit
2023-09-27  9:19                     ` [virtio-comment] " Chen, Jiqian
2023-09-27  9:19                       ` Chen, Jiqian

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=20230919082802-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Honglei1.Huang@amd.com \
    --cc=Jiqian.Chen@amd.com \
    --cc=Julia.Zhang@amd.com \
    --cc=Mikhail.Golubev-Ciuchea@opensynergy.com \
    --cc=Ray.Huang@amd.com \
    --cc=Stewart.Hildebrand@amd.com \
    --cc=airlied@redhat.com \
    --cc=bob.beckett@collabora.com \
    --cc=burzalodowa@gmail.com \
    --cc=gurchetansingh@chromium.org \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcandre.lureau@gmail.com \
    --cc=olvaffe@gmail.com \
    --cc=parav@nvidia.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 \
    --cc=xuanzhuo@linux.alibaba.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.