All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	mirela.grujic@greensocs.com,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Ani Sinha" <ani@anisinha.ca>, "Eric Blake" <eblake@redhat.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"open list:X86" <xen-devel@lists.xenproject.org>,
	"Paul Durrant" <paul@xen.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Eric Auger" <eric.auger@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Mark Burton" <mark.burton@greensocs.com>,
	"Edgar Iglesias" <edgari@xilinx.com>,
	"Igor Mammedov" <imammedo@redhat.com>
Subject: Re: [RFC PATCH v2 00/16] Initial support for machine creation via QMP
Date: Wed, 13 Oct 2021 08:16:27 +1000	[thread overview]
Message-ID: <CAKmqyKMUvtRPCp=FJMHcMdsECfJ_fRHBi4dA2N3gtqmPHspNJA@mail.gmail.com> (raw)
In-Reply-To: <20210922161405.140018-1-damien.hedde@greensocs.com>

On Thu, Sep 23, 2021 at 2:22 AM Damien Hedde <damien.hedde@greensocs.com> wrote:
>
> Hi,
>
> The goal of this work is to bring dynamic machine creation to QEMU:
> we want to setup a machine without compiling a specific machine C
> code. It would ease supporting highly configurable platforms (for
> example resulting from an automated design flow). The requirements
> for such configuration include begin able to specify the number of
> cores, available peripherals, emmory mapping, IRQ mapping, etc.
>
> This series focuses on the first step: populating a machine with
> devices during its creation. We propose patches to support this
> using QMP commands. This is a working set of patches and improves
> over the earlier rfc (posted in May):
> https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg03706.html
>
> Although it is working and could be merged, it is tag as an RFC:
> we probably need to discuss the conditions for allowing a device to
> be created at an early stage. Patches 6, 10 and 13, 15 and 16 depend
> on such conditions and are subject to change. Other patches are
> unrelated to this point.
>
> We address several issues in this series. They are detailed below.
>
> ## 1. Stoping QEMU to populate the machine with devices
>
> QEMU goes through several steps (called _machine phases_) when
> creating the machine: 'no-machine', 'machine-created',
> 'accel-created', 'initialized', and finally 'ready'. At 'ready'
> phase, QEMU is ready to start (see Paolo's page
> https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence for
> more details).
>
> Using the -preconfig CLI option, QEMU can be stopped today during
> the 'accel-created' phase. Then the 'x-exit-preconfig' QMP command
> triggers QEMU moving forwards to the completion of the machine
> creation ('ready' phase).
>
> The devices are created during the 'initialized' phase.
> In this phase the machine init() method has been executed and thus
> machine properties have been handled. Although the sysbus exists and
> the machine may have been populated by the init(),
> _machine_init_done_ notifiers have not been called yet. At this point
> we can add more devices to a machine.
>
> We propose to add 2 QMP commands:
> + The 'query-machine-phase' command would return the current machine
>   phase.
> + The 'x-machine-init' command would advance the machine phase to
>   'initialized'. 'x-exit-preconfig' could then still be used to
>   advance to the last phase.
>
> ## 2. Adding devices
>
> Right now, the user can create devices in 2 ways: using '-device' CLI
> option or 'device_add' QMP command. Both are executed after the
> machine is ready: such devices are hot-plugged. We propose to allow
> 'device_add' QMP command to be used during the 'initialized' phase.
>
> In this series, we keep the constraint that the device must be
> 'user-creatable' (this is a device class flag). We do not see any
> reason why a device the user can hot-plug could not be created at an
> earlier stage.
>
> This part is still RFC because, as Peter mentioned it (in this thread
> https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg01933.html),
> we may want additional or distinct conditions for:
> + device we can hot-plug
> + device we can add in '-preconfig' (cold-plug)
> We are open to suggestions. We could for example add a
> 'preconfig-creatable' or 'init-creatable' flag to device class, which
> can identify a set of devices we can create this way.
>
> The main addition is how we handle the case of sysbus devices. Sysbus
> devices are particular because unlike, for example, pci devices, you
> have to manually handle the memory mapping and interrupts wiring. So
> right now, a sysbus device is dynamically creatable (using -device
> CLI option or device_add QMP command) only if:
> + it is 'user_creatable' (like any other device),
> + and it is in the current machine sysbus device allow list.
>
> In this series, we propose to relax the second constraint during the
> earlier phases of machine creation so that when using -preconfig we
> can create any 'user-creatable' sysbus device. When the machine
> progresses to the 'ready' phase, sysbus devices creation will come
> back to the legacy behavior: it will be possible only based on the
> per-machine authorization basis.
>
> For sysbus devices, wiring interrupts is not a problem as we can use
> the 'qom-set' QMP command, but memory mapping is.
>
> ## 3. Memory mapping
>
> There is no point allowing the creation sysbus devices if we cannot
> map them onto the memory bus (the 'sysbus').
>
> As far as we know, right now, there is no way to add memory mapping
> for sysbus device using QMP commands. We propose a 'x-sysbus-mmio-map'
> command to do this. This command would only be allowed during the
> 'initialized' phase when using -preconfig.
>
> ## 4. Working example
>
> The last patches of the series add and modify devices in order to
> build a working machine starting from the 'none' machine.
>
> We add a new sysbus device modeling a simple memory (ram or rom). We
> also set 'user-creatable' flag of some sysbus devices. These are
> trivial patches, but they depends on the conditions we choose to allow
> creating devices with -preconfig. Therefore, there is really no need
> to review them until we settled on the device conditions first.
>
> With these devices (memory, ibex_uart, ibex_plic) we can dynamically
> configure a part (we did not add the timer, but we could) the
> opentitan machine very easily and run firmwares which demonstrates
> interrupts and memory-mapping are working.
>
> We use the existing qmp-shell script to issue machine devices
> from a qmp commands script file which contains qmp commands listed in
> a file.
>
> The following qmp commands add some memories, an interrupt controller
> and an uart with an interrupt.
>
> cat > opentitan.qmp <<EOF
> x-machine-init
>
> # ROM 0x00008000
> device_add        driver=sysbus-memory id=rom size=0x4000 readonly=true
> x-sysbus-mmio-map device=rom addr=32768
>
> # FLASH 0x20000000
> device_add        driver=sysbus-memory id=flash size=0x80000 readonly=true
> x-sysbus-mmio-map device=flash addr=536870912
>
> # RAM 0x10000000
> device_add        driver=sysbus-memory id=ram size=0x10000
> x-sysbus-mmio-map device=ram addr=268435456
>
> # PLIC 0x41010000
> device_add        driver=ibex-plic id=plic
> x-sysbus-mmio-map device=plic addr=1090584576
>
> # UART 0x40000000
> device_add        driver=ibex-uart id=uart chardev=serial0
> x-sysbus-mmio-map device=uart addr=1073741824
> qom-set path=uart property=sysbus-irq[1] value=plic/unnamed-gpio-in[2]
>
> x-exit-preconfig
> EOF
>
> We've put the opentitan.qmp and a firmware opentitan-echo.elf here
> (among some other qmp machine files we are working on):
> https://github.com/GreenSocs/qemu-qmp-machines

I am unable to access this repo, maybe it's not public?

Alistair


WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <alistair23@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"David Hildenbrand" <david@redhat.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Peter Xu" <peterx@redhat.com>,
	mirela.grujic@greensocs.com,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Ani Sinha" <ani@anisinha.ca>, "Eric Blake" <eblake@redhat.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Paul Durrant" <paul@xen.org>,
	"Eric Auger" <eric.auger@redhat.com>,
	"open list:X86" <xen-devel@lists.xenproject.org>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Mark Burton" <mark.burton@greensocs.com>,
	"Edgar Iglesias" <edgari@xilinx.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC PATCH v2 00/16] Initial support for machine creation via QMP
Date: Wed, 13 Oct 2021 08:16:27 +1000	[thread overview]
Message-ID: <CAKmqyKMUvtRPCp=FJMHcMdsECfJ_fRHBi4dA2N3gtqmPHspNJA@mail.gmail.com> (raw)
In-Reply-To: <20210922161405.140018-1-damien.hedde@greensocs.com>

On Thu, Sep 23, 2021 at 2:22 AM Damien Hedde <damien.hedde@greensocs.com> wrote:
>
> Hi,
>
> The goal of this work is to bring dynamic machine creation to QEMU:
> we want to setup a machine without compiling a specific machine C
> code. It would ease supporting highly configurable platforms (for
> example resulting from an automated design flow). The requirements
> for such configuration include begin able to specify the number of
> cores, available peripherals, emmory mapping, IRQ mapping, etc.
>
> This series focuses on the first step: populating a machine with
> devices during its creation. We propose patches to support this
> using QMP commands. This is a working set of patches and improves
> over the earlier rfc (posted in May):
> https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg03706.html
>
> Although it is working and could be merged, it is tag as an RFC:
> we probably need to discuss the conditions for allowing a device to
> be created at an early stage. Patches 6, 10 and 13, 15 and 16 depend
> on such conditions and are subject to change. Other patches are
> unrelated to this point.
>
> We address several issues in this series. They are detailed below.
>
> ## 1. Stoping QEMU to populate the machine with devices
>
> QEMU goes through several steps (called _machine phases_) when
> creating the machine: 'no-machine', 'machine-created',
> 'accel-created', 'initialized', and finally 'ready'. At 'ready'
> phase, QEMU is ready to start (see Paolo's page
> https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence for
> more details).
>
> Using the -preconfig CLI option, QEMU can be stopped today during
> the 'accel-created' phase. Then the 'x-exit-preconfig' QMP command
> triggers QEMU moving forwards to the completion of the machine
> creation ('ready' phase).
>
> The devices are created during the 'initialized' phase.
> In this phase the machine init() method has been executed and thus
> machine properties have been handled. Although the sysbus exists and
> the machine may have been populated by the init(),
> _machine_init_done_ notifiers have not been called yet. At this point
> we can add more devices to a machine.
>
> We propose to add 2 QMP commands:
> + The 'query-machine-phase' command would return the current machine
>   phase.
> + The 'x-machine-init' command would advance the machine phase to
>   'initialized'. 'x-exit-preconfig' could then still be used to
>   advance to the last phase.
>
> ## 2. Adding devices
>
> Right now, the user can create devices in 2 ways: using '-device' CLI
> option or 'device_add' QMP command. Both are executed after the
> machine is ready: such devices are hot-plugged. We propose to allow
> 'device_add' QMP command to be used during the 'initialized' phase.
>
> In this series, we keep the constraint that the device must be
> 'user-creatable' (this is a device class flag). We do not see any
> reason why a device the user can hot-plug could not be created at an
> earlier stage.
>
> This part is still RFC because, as Peter mentioned it (in this thread
> https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg01933.html),
> we may want additional or distinct conditions for:
> + device we can hot-plug
> + device we can add in '-preconfig' (cold-plug)
> We are open to suggestions. We could for example add a
> 'preconfig-creatable' or 'init-creatable' flag to device class, which
> can identify a set of devices we can create this way.
>
> The main addition is how we handle the case of sysbus devices. Sysbus
> devices are particular because unlike, for example, pci devices, you
> have to manually handle the memory mapping and interrupts wiring. So
> right now, a sysbus device is dynamically creatable (using -device
> CLI option or device_add QMP command) only if:
> + it is 'user_creatable' (like any other device),
> + and it is in the current machine sysbus device allow list.
>
> In this series, we propose to relax the second constraint during the
> earlier phases of machine creation so that when using -preconfig we
> can create any 'user-creatable' sysbus device. When the machine
> progresses to the 'ready' phase, sysbus devices creation will come
> back to the legacy behavior: it will be possible only based on the
> per-machine authorization basis.
>
> For sysbus devices, wiring interrupts is not a problem as we can use
> the 'qom-set' QMP command, but memory mapping is.
>
> ## 3. Memory mapping
>
> There is no point allowing the creation sysbus devices if we cannot
> map them onto the memory bus (the 'sysbus').
>
> As far as we know, right now, there is no way to add memory mapping
> for sysbus device using QMP commands. We propose a 'x-sysbus-mmio-map'
> command to do this. This command would only be allowed during the
> 'initialized' phase when using -preconfig.
>
> ## 4. Working example
>
> The last patches of the series add and modify devices in order to
> build a working machine starting from the 'none' machine.
>
> We add a new sysbus device modeling a simple memory (ram or rom). We
> also set 'user-creatable' flag of some sysbus devices. These are
> trivial patches, but they depends on the conditions we choose to allow
> creating devices with -preconfig. Therefore, there is really no need
> to review them until we settled on the device conditions first.
>
> With these devices (memory, ibex_uart, ibex_plic) we can dynamically
> configure a part (we did not add the timer, but we could) the
> opentitan machine very easily and run firmwares which demonstrates
> interrupts and memory-mapping are working.
>
> We use the existing qmp-shell script to issue machine devices
> from a qmp commands script file which contains qmp commands listed in
> a file.
>
> The following qmp commands add some memories, an interrupt controller
> and an uart with an interrupt.
>
> cat > opentitan.qmp <<EOF
> x-machine-init
>
> # ROM 0x00008000
> device_add        driver=sysbus-memory id=rom size=0x4000 readonly=true
> x-sysbus-mmio-map device=rom addr=32768
>
> # FLASH 0x20000000
> device_add        driver=sysbus-memory id=flash size=0x80000 readonly=true
> x-sysbus-mmio-map device=flash addr=536870912
>
> # RAM 0x10000000
> device_add        driver=sysbus-memory id=ram size=0x10000
> x-sysbus-mmio-map device=ram addr=268435456
>
> # PLIC 0x41010000
> device_add        driver=ibex-plic id=plic
> x-sysbus-mmio-map device=plic addr=1090584576
>
> # UART 0x40000000
> device_add        driver=ibex-uart id=uart chardev=serial0
> x-sysbus-mmio-map device=uart addr=1073741824
> qom-set path=uart property=sysbus-irq[1] value=plic/unnamed-gpio-in[2]
>
> x-exit-preconfig
> EOF
>
> We've put the opentitan.qmp and a firmware opentitan-echo.elf here
> (among some other qmp machine files we are working on):
> https://github.com/GreenSocs/qemu-qmp-machines

I am unable to access this repo, maybe it's not public?

Alistair


  parent reply	other threads:[~2021-10-12 22:17 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 16:13 [RFC PATCH v2 00/16] Initial support for machine creation via QMP Damien Hedde
2021-09-22 16:13 ` Damien Hedde
2021-09-22 16:13 ` [RFC PATCH v2 01/16] rename MachineInitPhase enum constants for QAPI compatibility Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-09-22 16:13 ` [RFC PATCH v2 02/16] qapi: Implement query-machine-phase QMP command Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-09-22 17:37   ` Philippe Mathieu-Daudé
2021-09-22 17:37     ` Philippe Mathieu-Daudé
2021-09-23 12:43     ` Damien Hedde
2021-09-23 12:43       ` Damien Hedde
2021-09-23 13:46       ` Ani Sinha
2021-09-23 13:46         ` Ani Sinha
2021-10-12 22:08   ` Alistair Francis
2021-10-12 22:08     ` Alistair Francis
2021-09-22 16:13 ` [RFC PATCH v2 03/16] qapi: Implement x-machine-init " Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-10-12 22:19   ` Alistair Francis
2021-10-12 22:19     ` Alistair Francis
2021-09-22 16:13 ` [RFC PATCH v2 04/16] softmmu/qdev-monitor: add error handling in qdev_set_id Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-10-13  7:10   ` Alistair Francis
2021-10-13  7:10     ` Alistair Francis
2021-10-13 14:30     ` Damien Hedde
2021-10-13 14:30       ` Damien Hedde
2021-09-22 16:13 ` [RFC PATCH v2 05/16] qdev-monitor: prevent conflicts between qmp/device_add and cli/-device Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-09-22 16:13 ` [RFC PATCH v2 06/16] qapi: Allow device_add to execute in machine initialized phase Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-10-12 22:25   ` Alistair Francis
2021-10-12 22:25     ` Alistair Francis
2021-09-22 16:13 ` [RFC PATCH v2 07/16] hw/core/machine: add machine_class_is_dynamic_sysbus_dev_allowed Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-09-23 10:51   ` Ani Sinha
2021-09-23 10:51     ` Ani Sinha
2021-09-23 13:07     ` Damien Hedde
2021-09-23 13:07       ` Damien Hedde
2021-09-22 16:13 ` [RFC PATCH v2 08/16] qdev-monitor: Check sysbus device type before creating it Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-10-12 22:42   ` Alistair Francis
2021-10-12 22:42     ` Alistair Francis
2021-09-22 16:13 ` [RFC PATCH v2 09/16] hw/core/machine: Remove the dynamic sysbus devices type check Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-10-12 23:07   ` Alistair Francis
2021-10-12 23:07     ` Alistair Francis
2021-09-22 16:13 ` [RFC PATCH v2 10/16] qdev-monitor: allow adding any sysbus device before machine is ready Damien Hedde
2021-09-22 16:13   ` Damien Hedde
2021-09-23 11:04   ` Ani Sinha
2021-09-23 11:04     ` Ani Sinha
2021-09-23 11:55     ` Ani Sinha
2021-09-23 11:55       ` Ani Sinha
2021-09-23 14:04       ` Damien Hedde
2021-09-23 14:04         ` Damien Hedde
2021-09-22 16:14 ` [RFC PATCH v2 11/16] softmmu/memory: add memory_region_try_add_subregion function Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-09-22 17:42   ` Philippe Mathieu-Daudé
2021-09-22 17:42     ` Philippe Mathieu-Daudé
2021-09-22 17:49   ` David Hildenbrand
2021-09-22 17:49     ` David Hildenbrand
2021-10-13  7:12   ` Alistair Francis
2021-10-13  7:12     ` Alistair Francis
2021-09-22 16:14 ` [RFC PATCH v2 12/16] add x-sysbus-mmio-map qmp command Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-10-13  7:16   ` Alistair Francis
2021-10-13  7:16     ` Alistair Francis
2021-09-22 16:14 ` [RFC PATCH v2 13/16] hw/mem/system-memory: add a memory sysbus device Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-09-22 16:14 ` [RFC PATCH v2 14/16] docs/system: add doc about the initialized machine phase and an example Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-09-22 16:14 ` [RFC PATCH v2 15/16] hw/char/ibex_uart: set user_creatable Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-09-22 16:14 ` [RFC PATCH v2 16/16] hw/intc/ibex_plic: " Damien Hedde
2021-09-22 16:14   ` Damien Hedde
2021-09-22 17:50 ` [RFC PATCH v2 00/16] Initial support for machine creation via QMP Philippe Mathieu-Daudé
2021-09-22 17:50   ` Philippe Mathieu-Daudé
2021-09-23 11:08   ` Damien Hedde
2021-09-23 11:08     ` Damien Hedde
2021-10-04 15:56 ` Damien Hedde
2021-10-04 15:56   ` Damien Hedde
2021-10-12 22:16 ` Alistair Francis [this message]
2021-10-12 22:16   ` Alistair Francis
2021-10-13  5:56   ` Mark Burton
2021-10-13  5:56     ` Mark Burton

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='CAKmqyKMUvtRPCp=FJMHcMdsECfJ_fRHBi4dA2N3gtqmPHspNJA@mail.gmail.com' \
    --to=alistair23@gmail.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=ani@anisinha.ca \
    --cc=anthony.perard@citrix.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=edgari@xilinx.com \
    --cc=ehabkost@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mark.burton@greensocs.com \
    --cc=mirela.grujic@greensocs.com \
    --cc=mst@redhat.com \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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 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.