From: Kirti Wankhede <kwankhede@nvidia.com> To: Paolo Bonzini <pbonzini@redhat.com>, John Ferlan <jferlan@redhat.com>, Michal Privoznik <mprivozn@redhat.com>, Alex Williamson <alex.williamson@redhat.com> Cc: "Song, Jike" <jike.song@intel.com>, "cjia@nvidia.com" <cjia@nvidia.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "libvir-list@redhat.com" <libvir-list@redhat.com>, "Tian, Kevin" <kevin.tian@intel.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "kraxel@redhat.com" <kraxel@redhat.com>, Laine Stump <laine@redhat.com>, "bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com> Subject: Re: [libvirt] [PATCH v7 0/4] Add Mediated device support Date: Sat, 3 Sep 2016 23:17:41 +0530 [thread overview] Message-ID: <3b920471-c69a-ccac-aa53-ae258442e82e@nvidia.com> (raw) In-Reply-To: <3169fcf3-1c1f-38cc-eb6d-3e8b4b8b1dd9@redhat.com> On 9/3/2016 6:37 PM, Paolo Bonzini wrote: > > > On 03/09/2016 13:56, John Ferlan wrote: >> On 09/02/2016 05:48 PM, Paolo Bonzini wrote: >>> On 02/09/2016 20:33, Kirti Wankhede wrote: >>>> <Alex> We could even do: >>>>>> >>>>>> echo $UUID1:$GROUPA > create >>>>>> >>>>>> where $GROUPA is the group ID of a previously created mdev device into >>>>>> which $UUID1 is to be created and added to the same group. >>>> </Alex> >>> >>> >From the point of view of libvirt, I think I prefer Alex's idea. >>> <group> could be an additional element in the nodedev-create XML: >>> >>> <device> >>> <name>my-vgpu</name> >>> <parent>pci_0000_86_00_0</parent> >>> <capability type='mdev'> >>> <type id='11'/> >>> <uuid>0695d332-7831-493f-9e71-1c85c8911a08</uuid> >>> <group>group1</group> >>> </capability> >>> </device> >>> >>> (should group also be a UUID?) >> I replied to earlier mail too, group number doesn't need to be UUID. It should be a unique number. I think in the discussion in bof someone mentioned about using domain's unique number that libvirt generates. That should also work. >> As long as create_group handles all the work and all libvirt does is >> call it, get the return status/error, and handle deleting the vGPU on >> error, then I guess it's doable. >> Yes that is the idea. Libvirt doesn't have to care about the groups. With Alex's proposal, as you mentioned above, libvirt have to provide group number to mdev_create, check return status and handle error case. echo $UUID1:$GROUP1 > mdev_create echo $UUID2:$GROUP1 > mdev_create would create two mdev devices assigned to same domain. >> Alternatively having multiple <type id='#'> in the XML and performing a >> single *mdev/create_group is an option. > > I don't really like the idea of a single nodedev-create creating > multiple devices, but that would work too. > >> That is, what is the "output" from create_group that gets added to the >> domain XML? How is that found? > > A new sysfs path is created, whose name depends on the UUID. The UUID > is used in a <hostdev> element in the domain XML and the sysfs path > appears in the QEMU command line. Kirti and Neo had examples in their > presentation at KVM Forum. > > If you create multiple devices in the same group, they are added to the > same IOMMU group so they must be used by the same VM. However they > don't have to be available from the beginning; they could be > hotplugged/hot-unplugged later, since from the point of view of the VM > those are just another PCI device. > >> Also, once the domain is running can a >> vGPU be added to the group? Removed? What allows/prevents? > > Kirti?... :) Yes, vGPU could be hot-plugged or hot-unplugged. This also depends on does vendor driver want to support that. For example, domain is running with two vGPUs $UUID1 and $UUID2 and user tried to hot-unplug vGPU $UUID2, vendor driver knows that domain is running and vGPU is being used in guest, so vendor driver can fail offline/close() call if they don't support hot-unplug. Similarly for hot-plug vendor driver can fail create call to not to support hot-plug. > > In principle I don't think anything should block vGPUs from different > groups being added to the same VM, but I have to defer to Alex and Kirti > again on this. > No, there should be one group per VM. >>> Since John brought up the topic of minimal XML, in this case it will be >>> like this: >>> >>> <device> >>> <name>my-vgpu</name> >>> <parent>pci_0000_86_00_0</parent> >>> <capability type='mdev'> >>> <type id='11'/> >>> </capability> >>> </device> >>> >>> The uuid will be autogenerated by libvirt and if there's no <group> (as >>> is common for VMs with only 1 vGPU) it will be a single-device group. >> >> The <name> could be ignored as it seems existing libvirt code wants to >> generate a name via udevGenerateDeviceName for other devices. I haven't >> studied it long enough, but I believe that's how those pci_####* names >> created. > > Yeah that makes sense. So we get down to a minimal XML that has just > parent, and capability with type in it; additional elements could be > name (ignored anyway), and within capability uuid and group. > Yes, this seems good. I would like to have one more capability here. Pulling here some suggestion from my previous mail: In the directory structure, a 'params' can take optional parameters. Libvirt then can set 'params' and then create mdev device. For example, param say 'disable_console_vnc=1' is set for type 11, then devices created of type 11 will have that param set unless it is cleared. └── mdev_supported_types ├── 11 │ ├── create │ ├── description │ └── max_instances │ └── params ├── 12 │ ├── create │ ├── description │ └── max_instances │ └── params └── 13 ├── create ├── description └── max_instances └── params So with that XML format would be: <device> <name>my-vgpu</name> <parent>pci_0000_86_00_0</parent> <capability type='mdev'> <type id='11'/> <group>group1</group> <params>disable_console_vnc=1</params> </capability> </device> and 'params' field should be just a string to libvirt and its optional also. If user want to provide extra parameter while creating vGPU device they should provide it in XML file as above to nodedev-create. Very initial proposal was to have this extra paramter list as a string to mdev_create itself as: echo $UUID1:$PARAMS > mdev_create I would like to know others opinions on whether it should be part of mdev_create input or a separate write to 'params' file in sysfs as in above directory structure. Kirti. > Thanks, > > Paolo >
WARNING: multiple messages have this Message-ID (diff)
From: Kirti Wankhede <kwankhede@nvidia.com> To: Paolo Bonzini <pbonzini@redhat.com>, John Ferlan <jferlan@redhat.com>, Michal Privoznik <mprivozn@redhat.com>, Alex Williamson <alex.williamson@redhat.com> Cc: "Song, Jike" <jike.song@intel.com>, "cjia@nvidia.com" <cjia@nvidia.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "libvir-list@redhat.com" <libvir-list@redhat.com>, "Tian, Kevin" <kevin.tian@intel.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "kraxel@redhat.com" <kraxel@redhat.com>, Laine Stump <laine@redhat.com>, "bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [libvirt] [PATCH v7 0/4] Add Mediated device support Date: Sat, 3 Sep 2016 23:17:41 +0530 [thread overview] Message-ID: <3b920471-c69a-ccac-aa53-ae258442e82e@nvidia.com> (raw) In-Reply-To: <3169fcf3-1c1f-38cc-eb6d-3e8b4b8b1dd9@redhat.com> On 9/3/2016 6:37 PM, Paolo Bonzini wrote: > > > On 03/09/2016 13:56, John Ferlan wrote: >> On 09/02/2016 05:48 PM, Paolo Bonzini wrote: >>> On 02/09/2016 20:33, Kirti Wankhede wrote: >>>> <Alex> We could even do: >>>>>> >>>>>> echo $UUID1:$GROUPA > create >>>>>> >>>>>> where $GROUPA is the group ID of a previously created mdev device into >>>>>> which $UUID1 is to be created and added to the same group. >>>> </Alex> >>> >>> >From the point of view of libvirt, I think I prefer Alex's idea. >>> <group> could be an additional element in the nodedev-create XML: >>> >>> <device> >>> <name>my-vgpu</name> >>> <parent>pci_0000_86_00_0</parent> >>> <capability type='mdev'> >>> <type id='11'/> >>> <uuid>0695d332-7831-493f-9e71-1c85c8911a08</uuid> >>> <group>group1</group> >>> </capability> >>> </device> >>> >>> (should group also be a UUID?) >> I replied to earlier mail too, group number doesn't need to be UUID. It should be a unique number. I think in the discussion in bof someone mentioned about using domain's unique number that libvirt generates. That should also work. >> As long as create_group handles all the work and all libvirt does is >> call it, get the return status/error, and handle deleting the vGPU on >> error, then I guess it's doable. >> Yes that is the idea. Libvirt doesn't have to care about the groups. With Alex's proposal, as you mentioned above, libvirt have to provide group number to mdev_create, check return status and handle error case. echo $UUID1:$GROUP1 > mdev_create echo $UUID2:$GROUP1 > mdev_create would create two mdev devices assigned to same domain. >> Alternatively having multiple <type id='#'> in the XML and performing a >> single *mdev/create_group is an option. > > I don't really like the idea of a single nodedev-create creating > multiple devices, but that would work too. > >> That is, what is the "output" from create_group that gets added to the >> domain XML? How is that found? > > A new sysfs path is created, whose name depends on the UUID. The UUID > is used in a <hostdev> element in the domain XML and the sysfs path > appears in the QEMU command line. Kirti and Neo had examples in their > presentation at KVM Forum. > > If you create multiple devices in the same group, they are added to the > same IOMMU group so they must be used by the same VM. However they > don't have to be available from the beginning; they could be > hotplugged/hot-unplugged later, since from the point of view of the VM > those are just another PCI device. > >> Also, once the domain is running can a >> vGPU be added to the group? Removed? What allows/prevents? > > Kirti?... :) Yes, vGPU could be hot-plugged or hot-unplugged. This also depends on does vendor driver want to support that. For example, domain is running with two vGPUs $UUID1 and $UUID2 and user tried to hot-unplug vGPU $UUID2, vendor driver knows that domain is running and vGPU is being used in guest, so vendor driver can fail offline/close() call if they don't support hot-unplug. Similarly for hot-plug vendor driver can fail create call to not to support hot-plug. > > In principle I don't think anything should block vGPUs from different > groups being added to the same VM, but I have to defer to Alex and Kirti > again on this. > No, there should be one group per VM. >>> Since John brought up the topic of minimal XML, in this case it will be >>> like this: >>> >>> <device> >>> <name>my-vgpu</name> >>> <parent>pci_0000_86_00_0</parent> >>> <capability type='mdev'> >>> <type id='11'/> >>> </capability> >>> </device> >>> >>> The uuid will be autogenerated by libvirt and if there's no <group> (as >>> is common for VMs with only 1 vGPU) it will be a single-device group. >> >> The <name> could be ignored as it seems existing libvirt code wants to >> generate a name via udevGenerateDeviceName for other devices. I haven't >> studied it long enough, but I believe that's how those pci_####* names >> created. > > Yeah that makes sense. So we get down to a minimal XML that has just > parent, and capability with type in it; additional elements could be > name (ignored anyway), and within capability uuid and group. > Yes, this seems good. I would like to have one more capability here. Pulling here some suggestion from my previous mail: In the directory structure, a 'params' can take optional parameters. Libvirt then can set 'params' and then create mdev device. For example, param say 'disable_console_vnc=1' is set for type 11, then devices created of type 11 will have that param set unless it is cleared. └── mdev_supported_types ├── 11 │ ├── create │ ├── description │ └── max_instances │ └── params ├── 12 │ ├── create │ ├── description │ └── max_instances │ └── params └── 13 ├── create ├── description └── max_instances └── params So with that XML format would be: <device> <name>my-vgpu</name> <parent>pci_0000_86_00_0</parent> <capability type='mdev'> <type id='11'/> <group>group1</group> <params>disable_console_vnc=1</params> </capability> </device> and 'params' field should be just a string to libvirt and its optional also. If user want to provide extra parameter while creating vGPU device they should provide it in XML file as above to nodedev-create. Very initial proposal was to have this extra paramter list as a string to mdev_create itself as: echo $UUID1:$PARAMS > mdev_create I would like to know others opinions on whether it should be part of mdev_create input or a separate write to 'params' file in sysfs as in above directory structure. Kirti. > Thanks, > > Paolo >
next prev parent reply other threads:[~2016-09-03 17:47 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-25 3:53 [PATCH v7 0/4] Add Mediated device support Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 3:53 ` [PATCH v7 1/4] vfio: Mediated device Core driver Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-09-08 8:09 ` Jike Song 2016-09-08 8:09 ` [Qemu-devel] " Jike Song 2016-09-08 9:38 ` Neo Jia 2016-09-08 9:38 ` [Qemu-devel] " Neo Jia 2016-09-09 6:26 ` Jike Song 2016-09-09 6:26 ` [Qemu-devel] " Jike Song 2016-09-09 17:48 ` Kirti Wankhede 2016-09-09 17:48 ` [Qemu-devel] " Kirti Wankhede 2016-09-09 18:42 ` Alex Williamson 2016-09-09 18:42 ` [Qemu-devel] " Alex Williamson 2016-09-09 19:55 ` Kirti Wankhede 2016-09-09 19:55 ` [Qemu-devel] " Kirti Wankhede 2016-09-12 5:10 ` Jike Song 2016-09-12 5:10 ` [Qemu-devel] " Jike Song 2016-09-12 7:49 ` Kirti Wankhede 2016-09-12 7:49 ` [Qemu-devel] " Kirti Wankhede 2016-09-12 15:53 ` Alex Williamson 2016-09-12 15:53 ` [Qemu-devel] " Alex Williamson 2016-09-19 7:08 ` Jike Song 2016-09-19 7:08 ` [Qemu-devel] " Jike Song 2016-09-19 17:29 ` Kirti Wankhede 2016-09-19 17:29 ` [Qemu-devel] " Kirti Wankhede 2016-09-19 18:11 ` Alex Williamson 2016-09-19 18:11 ` [Qemu-devel] " Alex Williamson 2016-09-19 20:09 ` Kirti Wankhede 2016-09-19 20:09 ` [Qemu-devel] " Kirti Wankhede 2016-09-19 20:59 ` Alex Williamson 2016-09-20 12:48 ` Jike Song 2016-09-20 12:48 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 2/4] vfio: VFIO driver for mediated devices Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 9:22 ` Dong Jia 2016-08-25 9:22 ` [Qemu-devel] " Dong Jia 2016-08-26 14:13 ` Kirti Wankhede 2016-08-26 14:13 ` [Qemu-devel] " Kirti Wankhede 2016-09-08 2:38 ` Jike Song 2016-09-08 2:38 ` [Qemu-devel] " Jike Song 2016-09-19 18:22 ` Kirti Wankhede 2016-09-19 18:22 ` Kirti Wankhede 2016-09-19 18:36 ` Alex Williamson 2016-09-19 18:36 ` Alex Williamson 2016-09-19 19:13 ` Kirti Wankhede 2016-09-19 19:13 ` Kirti Wankhede 2016-09-19 20:03 ` Alex Williamson 2016-09-19 20:03 ` Alex Williamson 2016-09-20 2:50 ` Jike Song 2016-09-20 16:24 ` Alex Williamson 2016-09-21 3:19 ` Jike Song 2016-09-21 4:51 ` Alex Williamson 2016-09-21 5:02 ` Jike Song 2016-09-08 2:45 ` Jike Song 2016-09-08 2:45 ` [Qemu-devel] " Jike Song 2016-09-13 2:35 ` Jike Song 2016-09-13 2:35 ` [Qemu-devel] " Jike Song 2016-09-20 5:48 ` Dong Jia Shi 2016-09-20 5:48 ` [Qemu-devel] " Dong Jia Shi 2016-09-20 6:37 ` Jike Song 2016-09-20 6:37 ` [Qemu-devel] " Jike Song 2016-09-20 12:53 ` Jike Song 2016-09-20 12:53 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 3/4] vfio iommu: Add support " Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-08-25 7:29 ` Dong Jia 2016-08-25 7:29 ` [Qemu-devel] " Dong Jia 2016-08-26 13:50 ` Kirti Wankhede 2016-08-26 13:50 ` [Qemu-devel] " Kirti Wankhede 2016-09-29 2:17 ` Jike Song 2016-09-29 2:17 ` [Qemu-devel] " Jike Song 2016-09-29 15:06 ` Kirti Wankhede 2016-09-29 15:06 ` [Qemu-devel] " Kirti Wankhede 2016-09-30 2:58 ` Jike Song 2016-09-30 2:58 ` [Qemu-devel] " Jike Song 2016-09-30 3:10 ` Jike Song 2016-09-30 3:10 ` [Qemu-devel] " Jike Song 2016-09-30 11:44 ` Kirti Wankhede 2016-09-30 11:44 ` [Qemu-devel] " Kirti Wankhede 2016-10-08 7:09 ` Jike Song 2016-10-08 7:09 ` [Qemu-devel] " Jike Song 2016-08-25 3:53 ` [PATCH v7 4/4] docs: Add Documentation for Mediated devices Kirti Wankhede 2016-08-25 3:53 ` [Qemu-devel] " Kirti Wankhede 2016-09-03 16:40 ` Kirti Wankhede 2016-09-03 16:40 ` [Qemu-devel] " Kirti Wankhede 2016-08-30 16:16 ` [PATCH v7 0/4] Add Mediated device support Alex Williamson 2016-08-30 16:16 ` [Qemu-devel] " Alex Williamson 2016-08-31 6:12 ` Tian, Kevin 2016-08-31 6:12 ` [Qemu-devel] " Tian, Kevin 2016-08-31 7:04 ` Jike Song 2016-08-31 7:04 ` [Qemu-devel] " Jike Song 2016-08-31 15:48 ` Alex Williamson 2016-08-31 15:48 ` [Qemu-devel] " Alex Williamson 2016-09-01 4:09 ` Tian, Kevin 2016-09-01 4:09 ` [Qemu-devel] " Tian, Kevin 2016-09-01 4:10 ` Tian, Kevin 2016-09-01 4:10 ` [Qemu-devel] " Tian, Kevin 2016-09-01 18:22 ` Kirti Wankhede 2016-09-01 18:22 ` [Qemu-devel] " Kirti Wankhede 2016-09-01 20:01 ` Alex Williamson 2016-09-01 20:01 ` [Qemu-devel] " Alex Williamson 2016-09-02 6:17 ` Kirti Wankhede 2016-09-02 6:17 ` [Qemu-devel] " Kirti Wankhede 2016-09-01 16:47 ` Michal Privoznik 2016-09-01 16:59 ` Alex Williamson 2016-09-01 16:59 ` [Qemu-devel] " Alex Williamson 2016-09-02 4:48 ` Michal Privoznik 2016-09-02 5:21 ` Kirti Wankhede 2016-09-02 10:05 ` Paolo Bonzini 2016-09-02 17:15 ` Kirti Wankhede 2016-09-02 17:25 ` Paolo Bonzini 2016-09-02 18:33 ` Kirti Wankhede 2016-09-02 20:29 ` [libvirt] " John Ferlan 2016-09-02 20:29 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-03 16:31 ` Kirti Wankhede 2016-09-03 16:31 ` [Qemu-devel] " Kirti Wankhede 2016-09-06 17:54 ` [libvirt] [Qemu-devel] " Alex Williamson 2016-09-06 17:54 ` [Qemu-devel] [libvirt] " Alex Williamson 2016-09-02 21:48 ` [Qemu-devel] " Paolo Bonzini 2016-09-03 11:56 ` [libvirt] " John Ferlan 2016-09-03 11:56 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-03 13:07 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-03 13:07 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-03 17:47 ` Kirti Wankhede [this message] 2016-09-03 17:47 ` Kirti Wankhede 2016-09-03 16:34 ` [Qemu-devel] " Kirti Wankhede 2016-09-06 17:40 ` Alex Williamson 2016-09-06 19:35 ` Kirti Wankhede 2016-09-06 21:28 ` Alex Williamson 2016-09-07 8:22 ` Tian, Kevin 2016-09-07 8:22 ` Tian, Kevin 2016-09-07 16:00 ` Alex Williamson 2016-09-07 16:15 ` Kirti Wankhede 2016-09-07 16:44 ` Alex Williamson 2016-09-07 18:06 ` Kirti Wankhede 2016-09-07 22:13 ` Alex Williamson 2016-09-08 18:48 ` Kirti Wankhede 2016-09-08 20:51 ` Alex Williamson 2016-09-07 18:17 ` Neo Jia 2016-09-07 18:27 ` Daniel P. Berrange 2016-09-07 18:32 ` Neo Jia 2016-09-07 6:48 ` Tian, Kevin 2016-09-07 6:48 ` Tian, Kevin 2016-09-02 20:19 ` [libvirt] " John Ferlan 2016-09-02 20:19 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-02 21:44 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-02 21:44 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-02 23:57 ` [libvirt] [Qemu-devel] " Laine Stump 2016-09-02 23:57 ` [Qemu-devel] [libvirt] " Laine Stump 2016-09-03 16:49 ` [libvirt] [Qemu-devel] " Kirti Wankhede 2016-09-03 16:49 ` [Qemu-devel] [libvirt] " Kirti Wankhede 2016-09-05 7:52 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-05 7:52 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-03 11:57 ` [libvirt] [Qemu-devel] " John Ferlan 2016-09-03 11:57 ` [Qemu-devel] [libvirt] " John Ferlan 2016-09-05 7:54 ` [libvirt] [Qemu-devel] " Paolo Bonzini 2016-09-05 7:54 ` [Qemu-devel] [libvirt] " Paolo Bonzini 2016-09-02 17:55 ` [libvirt] [Qemu-devel] " Laine Stump 2016-09-02 17:55 ` [Qemu-devel] [libvirt] " Laine Stump 2016-09-02 19:15 ` Alex Williamson 2016-09-02 19:15 ` [Qemu-devel] " Alex Williamson
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=3b920471-c69a-ccac-aa53-ae258442e82e@nvidia.com \ --to=kwankhede@nvidia.com \ --cc=alex.williamson@redhat.com \ --cc=bjsdjshi@linux.vnet.ibm.com \ --cc=cjia@nvidia.com \ --cc=jferlan@redhat.com \ --cc=jike.song@intel.com \ --cc=kevin.tian@intel.com \ --cc=kraxel@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=laine@redhat.com \ --cc=libvir-list@redhat.com \ --cc=mprivozn@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.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: 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.