From: Ram Pai <linuxram@us.ibm.com> To: Halil Pasic <pasic@linux.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com>, Greg Kurz <groug@kaod.org>, pair@us.ibm.com, brijesh.singh@amd.com, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, frankja@linux.ibm.com, david@redhat.com, mdroth@linux.vnet.ibm.com, borntraeger@de.ibm.com, David Gibson <david@gibson.dropbear.id.au>, thuth@redhat.com, Eduardo Habkost <ehabkost@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, dgilbert@redhat.com, qemu-s390x@nongnu.org, rth@twiddle.net, berrange@redhat.com, Marcelo Tosatti <mtosatti@redhat.com>, qemu-ppc@nongnu.org, pbonzini@redhat.com Subject: RE: [for-6.0 v5 11/13] spapr: PEF: prevent migration Date: Mon, 4 Jan 2021 10:40:26 -0800 [thread overview] Message-ID: <20210104184026.GD4102@ram-ibm-com.ibm.com> (raw) In-Reply-To: <20210104134629.49997b53.pasic@linux.ibm.com> On Mon, Jan 04, 2021 at 01:46:29PM +0100, Halil Pasic wrote: > On Sun, 3 Jan 2021 23:15:50 -0800 > Ram Pai <linuxram@us.ibm.com> wrote: > > > On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote: > > > On Thu, 17 Dec 2020 15:15:30 +0100 > [..] > > > > > > > > +int kvmppc_svm_init(SecurableGuestMemory *sgm, Error **errp) > > > > > > > > { > > > > > > > > if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURABLE_GUEST)) { > > > > > > > > error_setg(errp, > > > > > > > > @@ -54,6 +58,11 @@ static int kvmppc_svm_init(Error **errp) > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > + /* add migration blocker */ > > > > > > > > + error_setg(&pef_mig_blocker, "PEF: Migration is not implemented"); > > > > > > > > + /* NB: This can fail if --only-migratable is used */ > > > > > > > > + migrate_add_blocker(pef_mig_blocker, &error_fatal); > > > > > > > > > > > > > > Just so that I understand: is PEF something that is enabled by the host > > > > > > > (and the guest is either secured or doesn't start), or is it using a > > > > > > > model like s390x PV where the guest initiates the transition into > > > > > > > secured mode? > > > > > > > > > > > > Like s390x PV it's initiated by the guest. > > > > > > > > > > > > > Asking because s390x adds the migration blocker only when the > > > > > > > transition is actually happening (i.e. guests that do not transition > > > > > > > into secure mode remain migratable.) This has the side effect that you > > > > > > > might be able to start a machine with --only-migratable that > > > > > > > transitions into a non-migratable machine via a guest action, if I'm > > > > > > > not mistaken. Without the new object, I don't see a way to block with > > > > > > > --only-migratable; with it, we should be able to do that. Not sure what > > > > > > > the desirable behaviour is here. > > > > > > > > > > > > > > The purpose of --only-migratable is specifically to prevent the machine > > > > to transition to a non-migrate state IIUC. The guest transition to > > > > secure mode should be nacked in this case. > > > > > > Yes, that's what happens for s390x: The guest tries to transition, QEMU > > > can't add a migration blocker and fails the instruction used for > > > transitioning, the guest sees the error. > > > > > > The drawback is that we see the failure only when we already launched > > > the machine and the guest tries to transition. If I start QEMU with > > > --only-migratable, it will refuse to start when non-migratable devices > > > are configured in the command line, so I see the issue right from the > > > start. (For s390x, that would possibly mean that we should not even > > > present the cpu feature bit when only_migratable is set?) > > > > What happens in s390x, if the guest tries to transition to secure, when > > the secure object is NOT configured on the machine? > > > > Nothing in particular. > > > On PEF systems, the transition fails and the guest is terminated. > > > > My point is -- QEMU will not be able to predict in advance, what the > > guest might or might not do, regardless of what devices and objects are > > configured in the machine. If the guest does something unexpected, it > > has to be terminated. > > We can't fail transition to secure when the secure object is not > configured on the machine, because that would break pre-existing > setups. So the instruction to switch-to-secure; which I believe is a ultracall on S390, will return success even though the switch-to-secure has failed? Will the guest continue as a normal guest or as a secure guest? > This feature is still to be shipped, but secure execution has > already been shipped, but without migration support. > > That's why when you have both the secure object configured, and mandate > migratability, the we can fail. Actually we should fail now, because the > two options are not compatible: you can't have a qemu that is guaranteed > to be migratable, and guaranteed to be able to operate in secure > execution mode today. Failing early, and not on the guests opt-in would > be preferable. > > After migration support is added, the combo should be fine, and probably > also the default for secure execution machines. > > > > > So one possible design choice is to let the guest know that migration > > must be facilitated. It can then decide if it wants to continue as a > > normal VM or terminate itself, or take the plunge and switch to secure. > > A well behaving guest will not switch to secure. > > > > I don't understand this point. Sorry. Qemu will present the 'must-support-migrate' and the 'secure-object' capability to the guest. The secure-aware guest, has three choices (a) terminate itself. OR (b) not call the switch-to-secure ucall, and continue as normal guest. OR (c) call the switch-to-secure ucall. Legacy guests which are not aware of secure-object, will continue to do (b). New Guests which are secure-object aware, will observe that 'must-support-migrate' and 'secure-object' capabilities are incompatible. Hence will choose (a) or (b), but will never choose (c). The main difference between my proposal and the other proposal is... In my proposal the guest makes the compatibility decision and acts accordingly. In the other proposal QEMU makes the compatibility decision and acts accordingly. I argue that QEMU cannot make a good compatibility decision, because it wont know in advance, if the guest will or will-not switch-to-secure. RP
WARNING: multiple messages have this Message-ID (diff)
From: Ram Pai <linuxram@us.ibm.com> To: Halil Pasic <pasic@linux.ibm.com> Cc: pair@us.ibm.com, Cornelia Huck <cohuck@redhat.com>, brijesh.singh@amd.com, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, frankja@linux.ibm.com, david@redhat.com, mdroth@linux.vnet.ibm.com, borntraeger@de.ibm.com, David Gibson <david@gibson.dropbear.id.au>, thuth@redhat.com, Eduardo Habkost <ehabkost@redhat.com>, Richard Henderson <richard.henderson@linaro.org>, Greg Kurz <groug@kaod.org>, dgilbert@redhat.com, qemu-s390x@nongnu.org, rth@twiddle.net, berrange@redhat.com, Marcelo Tosatti <mtosatti@redhat.com>, qemu-ppc@nongnu.org, pbonzini@redhat.com Subject: RE: [for-6.0 v5 11/13] spapr: PEF: prevent migration Date: Mon, 4 Jan 2021 10:40:26 -0800 [thread overview] Message-ID: <20210104184026.GD4102@ram-ibm-com.ibm.com> (raw) In-Reply-To: <20210104134629.49997b53.pasic@linux.ibm.com> On Mon, Jan 04, 2021 at 01:46:29PM +0100, Halil Pasic wrote: > On Sun, 3 Jan 2021 23:15:50 -0800 > Ram Pai <linuxram@us.ibm.com> wrote: > > > On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote: > > > On Thu, 17 Dec 2020 15:15:30 +0100 > [..] > > > > > > > > +int kvmppc_svm_init(SecurableGuestMemory *sgm, Error **errp) > > > > > > > > { > > > > > > > > if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURABLE_GUEST)) { > > > > > > > > error_setg(errp, > > > > > > > > @@ -54,6 +58,11 @@ static int kvmppc_svm_init(Error **errp) > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > + /* add migration blocker */ > > > > > > > > + error_setg(&pef_mig_blocker, "PEF: Migration is not implemented"); > > > > > > > > + /* NB: This can fail if --only-migratable is used */ > > > > > > > > + migrate_add_blocker(pef_mig_blocker, &error_fatal); > > > > > > > > > > > > > > Just so that I understand: is PEF something that is enabled by the host > > > > > > > (and the guest is either secured or doesn't start), or is it using a > > > > > > > model like s390x PV where the guest initiates the transition into > > > > > > > secured mode? > > > > > > > > > > > > Like s390x PV it's initiated by the guest. > > > > > > > > > > > > > Asking because s390x adds the migration blocker only when the > > > > > > > transition is actually happening (i.e. guests that do not transition > > > > > > > into secure mode remain migratable.) This has the side effect that you > > > > > > > might be able to start a machine with --only-migratable that > > > > > > > transitions into a non-migratable machine via a guest action, if I'm > > > > > > > not mistaken. Without the new object, I don't see a way to block with > > > > > > > --only-migratable; with it, we should be able to do that. Not sure what > > > > > > > the desirable behaviour is here. > > > > > > > > > > > > > > The purpose of --only-migratable is specifically to prevent the machine > > > > to transition to a non-migrate state IIUC. The guest transition to > > > > secure mode should be nacked in this case. > > > > > > Yes, that's what happens for s390x: The guest tries to transition, QEMU > > > can't add a migration blocker and fails the instruction used for > > > transitioning, the guest sees the error. > > > > > > The drawback is that we see the failure only when we already launched > > > the machine and the guest tries to transition. If I start QEMU with > > > --only-migratable, it will refuse to start when non-migratable devices > > > are configured in the command line, so I see the issue right from the > > > start. (For s390x, that would possibly mean that we should not even > > > present the cpu feature bit when only_migratable is set?) > > > > What happens in s390x, if the guest tries to transition to secure, when > > the secure object is NOT configured on the machine? > > > > Nothing in particular. > > > On PEF systems, the transition fails and the guest is terminated. > > > > My point is -- QEMU will not be able to predict in advance, what the > > guest might or might not do, regardless of what devices and objects are > > configured in the machine. If the guest does something unexpected, it > > has to be terminated. > > We can't fail transition to secure when the secure object is not > configured on the machine, because that would break pre-existing > setups. So the instruction to switch-to-secure; which I believe is a ultracall on S390, will return success even though the switch-to-secure has failed? Will the guest continue as a normal guest or as a secure guest? > This feature is still to be shipped, but secure execution has > already been shipped, but without migration support. > > That's why when you have both the secure object configured, and mandate > migratability, the we can fail. Actually we should fail now, because the > two options are not compatible: you can't have a qemu that is guaranteed > to be migratable, and guaranteed to be able to operate in secure > execution mode today. Failing early, and not on the guests opt-in would > be preferable. > > After migration support is added, the combo should be fine, and probably > also the default for secure execution machines. > > > > > So one possible design choice is to let the guest know that migration > > must be facilitated. It can then decide if it wants to continue as a > > normal VM or terminate itself, or take the plunge and switch to secure. > > A well behaving guest will not switch to secure. > > > > I don't understand this point. Sorry. Qemu will present the 'must-support-migrate' and the 'secure-object' capability to the guest. The secure-aware guest, has three choices (a) terminate itself. OR (b) not call the switch-to-secure ucall, and continue as normal guest. OR (c) call the switch-to-secure ucall. Legacy guests which are not aware of secure-object, will continue to do (b). New Guests which are secure-object aware, will observe that 'must-support-migrate' and 'secure-object' capabilities are incompatible. Hence will choose (a) or (b), but will never choose (c). The main difference between my proposal and the other proposal is... In my proposal the guest makes the compatibility decision and acts accordingly. In the other proposal QEMU makes the compatibility decision and acts accordingly. I argue that QEMU cannot make a good compatibility decision, because it wont know in advance, if the guest will or will-not switch-to-secure. RP
next prev parent reply other threads:[~2021-01-04 18:41 UTC|newest] Thread overview: 186+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-04 5:44 [for-6.0 v5 00/13] Generalize memory encryption models David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 01/13] qom: Allow optional sugar props David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 12:57 ` Cornelia Huck 2020-12-04 12:57 ` Cornelia Huck 2020-12-14 21:25 ` Eduardo Habkost 2020-12-14 21:25 ` Eduardo Habkost 2021-01-11 18:04 ` Philippe Mathieu-Daudé 2021-01-11 18:04 ` Philippe Mathieu-Daudé 2020-12-04 5:44 ` [for-6.0 v5 02/13] securable guest memory: Introduce new securable guest memory base class David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 03/13] securable guest memory: Handle memory encryption via interface David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 13:10 ` Cornelia Huck 2020-12-04 13:10 ` Cornelia Huck 2021-01-08 4:03 ` David Gibson 2021-01-08 4:03 ` David Gibson 2021-01-12 3:49 ` David Gibson 2021-01-12 3:49 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 04/13] securable guest memory: Move side effect out of machine_set_memory_encryption() David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 05/13] securable guest memory: Rework the "memory-encryption" property David Gibson 2020-12-04 5:44 ` David Gibson 2021-01-11 18:09 ` Philippe Mathieu-Daudé 2021-01-11 18:09 ` Philippe Mathieu-Daudé 2020-12-04 5:44 ` [for-6.0 v5 06/13] securable guest memory: Decouple kvm_memcrypt_*() helpers from KVM David Gibson 2020-12-04 5:44 ` David Gibson 2021-01-11 18:13 ` Philippe Mathieu-Daudé 2021-01-11 18:13 ` Philippe Mathieu-Daudé 2021-01-12 3:03 ` David Gibson 2021-01-12 3:03 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 07/13] sev: Add Error ** to sev_kvm_init() David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-14 16:50 ` Cornelia Huck 2020-12-14 16:50 ` Cornelia Huck 2020-12-04 5:44 ` [for-6.0 v5 08/13] securable guest memory: Introduce sgm "ready" flag David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-14 17:00 ` Cornelia Huck 2020-12-14 17:00 ` Cornelia Huck 2020-12-17 5:38 ` David Gibson 2020-12-17 5:38 ` David Gibson 2020-12-17 11:24 ` Cornelia Huck 2020-12-17 11:24 ` Cornelia Huck 2020-12-04 5:44 ` [for-6.0 v5 09/13] securable guest memory: Move SEV initialization into arch specific code David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 10/13] spapr: Add PEF based securable guest memory David Gibson 2020-12-04 5:44 ` David Gibson 2021-01-05 23:34 ` Ram Pai 2021-01-05 23:34 ` Ram Pai 2021-01-08 0:34 ` David Gibson 2021-01-08 0:34 ` David Gibson 2020-12-04 5:44 ` [for-6.0 v5 11/13] spapr: PEF: prevent migration David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-14 17:22 ` Cornelia Huck 2020-12-14 17:22 ` Cornelia Huck 2020-12-17 5:47 ` David Gibson 2020-12-17 5:47 ` David Gibson 2020-12-17 11:38 ` Cornelia Huck 2020-12-17 11:38 ` Cornelia Huck 2020-12-17 14:15 ` Greg Kurz 2020-12-17 14:15 ` Greg Kurz 2020-12-18 11:41 ` Cornelia Huck 2020-12-18 11:41 ` Cornelia Huck 2020-12-18 12:08 ` Dr. David Alan Gilbert 2020-12-18 12:08 ` Dr. David Alan Gilbert 2021-01-04 7:15 ` Ram Pai 2021-01-04 7:15 ` Ram Pai 2021-01-04 12:46 ` [EXTERNAL] " Halil Pasic 2021-01-04 12:46 ` Halil Pasic 2021-01-04 18:40 ` Ram Pai [this message] 2021-01-04 18:40 ` Ram Pai 2021-01-05 10:56 ` [EXTERNAL] " Halil Pasic 2021-01-05 10:56 ` Halil Pasic 2021-01-05 20:41 ` Ram Pai 2021-01-05 20:41 ` Ram Pai 2021-01-11 16:59 ` Cornelia Huck 2021-01-11 16:59 ` Cornelia Huck 2021-01-11 19:58 ` Ram Pai 2021-01-11 19:58 ` Ram Pai 2021-01-12 8:19 ` Cornelia Huck 2021-01-12 8:19 ` Cornelia Huck 2021-01-12 18:55 ` Ram Pai 2021-01-12 18:55 ` Ram Pai 2021-01-13 8:06 ` Cornelia Huck 2021-01-13 8:06 ` Cornelia Huck 2021-01-15 18:55 ` Ram Pai 2021-01-15 18:55 ` Ram Pai 2021-01-19 8:19 ` Cornelia Huck 2021-01-19 8:19 ` Cornelia Huck 2021-01-19 9:59 ` Daniel P. Berrangé 2021-01-19 9:59 ` Daniel P. Berrangé 2021-01-14 11:23 ` Daniel P. Berrangé 2021-01-14 11:23 ` Daniel P. Berrangé 2021-01-13 12:42 ` Dr. David Alan Gilbert 2021-01-13 12:42 ` Dr. David Alan Gilbert 2021-01-14 10:28 ` Christian Borntraeger 2021-01-14 10:28 ` Christian Borntraeger 2021-01-14 10:36 ` Dr. David Alan Gilbert 2021-01-14 10:36 ` Dr. David Alan Gilbert 2021-01-14 10:52 ` Christian Borntraeger 2021-01-14 10:52 ` Christian Borntraeger 2021-01-14 11:05 ` Cornelia Huck 2021-01-14 11:05 ` Cornelia Huck 2021-01-14 11:45 ` Dr. David Alan Gilbert 2021-01-14 11:45 ` Dr. David Alan Gilbert 2021-01-14 11:50 ` Christian Borntraeger 2021-01-14 11:50 ` Christian Borntraeger 2021-01-14 12:20 ` Daniel P. Berrangé 2021-01-14 12:20 ` Daniel P. Berrangé 2021-01-14 14:04 ` Cornelia Huck 2021-01-14 14:04 ` Cornelia Huck 2021-01-14 14:09 ` Christian Borntraeger 2021-01-14 14:09 ` Christian Borntraeger 2021-01-14 14:15 ` Daniel P. Berrangé 2021-01-14 14:15 ` Daniel P. Berrangé 2021-01-14 15:25 ` Christian Borntraeger 2021-01-14 15:25 ` Christian Borntraeger 2021-01-14 15:33 ` Daniel P. Berrangé 2021-01-14 15:33 ` Daniel P. Berrangé 2021-01-15 18:24 ` Ram Pai 2021-01-15 18:24 ` Ram Pai 2021-01-14 11:25 ` Daniel P. Berrangé 2021-01-14 11:25 ` Daniel P. Berrangé 2021-01-14 23:51 ` David Gibson 2021-01-14 23:51 ` David Gibson 2021-01-18 17:39 ` Dr. David Alan Gilbert 2021-01-18 17:39 ` Dr. David Alan Gilbert 2021-01-19 8:28 ` Christian Borntraeger 2021-01-19 8:28 ` Christian Borntraeger 2021-01-19 8:34 ` Cornelia Huck 2021-01-19 8:34 ` Cornelia Huck 2020-12-04 5:44 ` [for-6.0 v5 12/13] securable guest memory: Alter virtio default properties for protected guests David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-04 8:10 ` Christian Borntraeger 2020-12-04 8:10 ` Christian Borntraeger 2020-12-04 8:17 ` Cornelia Huck 2020-12-04 8:17 ` Cornelia Huck 2020-12-04 8:29 ` Christian Borntraeger 2020-12-04 8:29 ` Christian Borntraeger 2020-12-04 14:43 ` Halil Pasic 2020-12-04 14:43 ` Halil Pasic 2020-12-08 1:54 ` David Gibson 2020-12-08 1:54 ` David Gibson 2020-12-08 8:16 ` Christian Borntraeger 2020-12-08 8:16 ` Christian Borntraeger 2020-12-08 10:28 ` Halil Pasic 2020-12-08 10:28 ` Halil Pasic 2020-12-08 12:50 ` Cornelia Huck 2020-12-08 12:50 ` Cornelia Huck 2020-12-17 5:53 ` David Gibson 2020-12-17 5:53 ` David Gibson 2020-12-04 17:04 ` Cornelia Huck 2020-12-04 17:04 ` Cornelia Huck 2020-12-04 5:44 ` [for-6.0 v5 13/13] s390: Recognize securable-guest-memory option David Gibson 2020-12-04 5:44 ` David Gibson 2020-12-15 11:45 ` Cornelia Huck 2020-12-15 11:45 ` Cornelia Huck 2020-12-17 5:54 ` David Gibson 2020-12-17 5:54 ` David Gibson 2020-12-04 8:06 ` [for-6.0 v5 00/13] Generalize memory encryption models Christian Borntraeger 2020-12-04 8:06 ` Christian Borntraeger 2020-12-04 13:02 ` Cornelia Huck 2020-12-04 13:02 ` Cornelia Huck 2020-12-04 13:07 ` Dr. David Alan Gilbert 2020-12-04 13:07 ` Dr. David Alan Gilbert 2020-12-04 13:12 ` Cornelia Huck 2020-12-04 13:12 ` Cornelia Huck 2020-12-08 2:57 ` David Gibson 2020-12-08 2:57 ` David Gibson 2020-12-08 12:43 ` Cornelia Huck 2020-12-08 12:43 ` Cornelia Huck 2020-12-17 6:21 ` David Gibson 2020-12-17 6:21 ` David Gibson 2020-12-17 11:43 ` Cornelia Huck 2020-12-17 11:43 ` Cornelia Huck 2020-12-04 13:25 ` Daniel P. Berrangé 2020-12-04 13:25 ` Daniel P. Berrangé 2020-12-04 13:51 ` Halil Pasic 2020-12-04 13:51 ` Halil Pasic 2020-12-08 2:54 ` David Gibson 2020-12-08 2:54 ` David Gibson 2020-12-04 9:50 ` Daniel P. Berrangé 2020-12-04 9:50 ` Daniel P. Berrangé 2021-01-12 3:02 ` David Gibson 2021-01-12 3:02 ` David Gibson
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=20210104184026.GD4102@ram-ibm-com.ibm.com \ --to=linuxram@us.ibm.com \ --cc=berrange@redhat.com \ --cc=borntraeger@de.ibm.com \ --cc=brijesh.singh@amd.com \ --cc=cohuck@redhat.com \ --cc=david@gibson.dropbear.id.au \ --cc=david@redhat.com \ --cc=dgilbert@redhat.com \ --cc=ehabkost@redhat.com \ --cc=frankja@linux.ibm.com \ --cc=groug@kaod.org \ --cc=kvm@vger.kernel.org \ --cc=mdroth@linux.vnet.ibm.com \ --cc=mst@redhat.com \ --cc=mtosatti@redhat.com \ --cc=pair@us.ibm.com \ --cc=pasic@linux.ibm.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=qemu-ppc@nongnu.org \ --cc=qemu-s390x@nongnu.org \ --cc=richard.henderson@linaro.org \ --cc=rth@twiddle.net \ --cc=thuth@redhat.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: linkBe 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.