* Question regarding VIOT proposal @ 2020-11-05 0:13 Yinghan Yang via iommu 2020-11-05 13:45 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Yinghan Yang via iommu @ 2020-11-05 0:13 UTC (permalink / raw) To: iommu; +Cc: Alexander Grest [-- Attachment #1.1: Type: text/plain, Size: 503 bytes --] Hi iommu developers, I have a question regarding the recent VIOT submission for supporting paravirtualized IOMMU in guests. The spec defines PCI Range Node Structure (5.2.30.3) that maps to a single PCI segment. Is it possible for the new table to express that an IOMMU covers all PCI segments? This could help support scenarios where: 1. Devices are dynamically assigned to guests during runtime 2. Devices in the same guests are assigned to different segments. Thanks, Yinghan [-- Attachment #1.2: Type: text/html, Size: 4314 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Question regarding VIOT proposal 2020-11-05 0:13 Question regarding VIOT proposal Yinghan Yang via iommu @ 2020-11-05 13:45 ` Jean-Philippe Brucker 2020-11-05 22:05 ` [EXTERNAL] " Yinghan Yang via iommu 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2020-11-05 13:45 UTC (permalink / raw) To: Yinghan Yang Cc: jean-philippe, kevin.tian, mst, iommu, sebastien.boeuf, Alexander Grest, ahs3 Hi, On Thu, Nov 05, 2020 at 12:13:53AM +0000, Yinghan Yang via iommu wrote: > Hi iommu developers, > > > > I have a question regarding the recent VIOT submission for supporting > paravirtualized IOMMU in guests. The spec defines PCI Range Node Structure > (5.2.30.3) that maps to a single PCI segment. (To provide some context for other readers, a description of the node is available at https://jpbrucker.net/virtio-iommu/viot/viot-v8.pdf) > > > > Is it possible for the new table to express that an IOMMU covers all PCI > segments? This could help support scenarios where: > > > > 1. Devices are dynamically assigned to guests during runtime > 2. Devices in the same guests are assigned to different segments. This is possible with the current descriptor, assuming the PCI segments are static. The platform can provide a PCI Range Node for each segment, with a BDF range 0 - 0xffff. For example a table could describe: * PCI Range Node * PCI Segment: 0 * BDF start: 0 * BDF end: 0xffff * Endpoint start: 0 * Output node: &viommu * PCI Range Node * PCI Segment: 1 * BDF start: 0 * BDF end: 0xffff * Endpoint start: 0x10000 * Output node: &viommu * viommu Node Then the IOMMU covers all PCI devices on the two segments. To identify a device when configuring DMA translation, the IOMMU driver builds a 32-bit endpoint ID = Endpoint start + BDF. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [EXTERNAL] Re: Question regarding VIOT proposal 2020-11-05 13:45 ` Jean-Philippe Brucker @ 2020-11-05 22:05 ` Yinghan Yang via iommu 2020-11-06 13:57 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Yinghan Yang via iommu @ 2020-11-05 22:05 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, ahs3 Hi Jean, Thank you for the clarifications. In cases where a large range of PCI segments may be assigned to guest, would it make sense to describe this configuration as base + count. Currently, one would have to describe them individually. Yinghan -----Original Message----- From: Jean-Philippe Brucker <jean-philippe@linaro.org> Sent: Thursday, November 5, 2020 5:45 AM To: Yinghan Yang <Yinghan.Yang@microsoft.com> Cc: iommu@lists.linux-foundation.org; Alexander Grest <Alexander.Grest@microsoft.com>; eric.auger@redhat.com; jean-philippe@linaro.org; joro@8bytes.org; kevin.tian@intel.com; lorenzo.pieralisi@arm.com; mst@redhat.com; Boeuf, Sebastien <sebastien.boeuf@intel.com>; ahs3@redhat.com Subject: [EXTERNAL] Re: Question regarding VIOT proposal Hi, On Thu, Nov 05, 2020 at 12:13:53AM +0000, Yinghan Yang via iommu wrote: > Hi iommu developers, > > > > I have a question regarding the recent VIOT submission for supporting > paravirtualized IOMMU in guests. The spec defines PCI Range Node > Structure > (5.2.30.3) that maps to a single PCI segment. (To provide some context for other readers, a description of the node is available at https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fvirtio-iommu%2Fviot%2Fviot-v8.pdf&data=04%7C01%7CYinghan.Yang%40microsoft.com%7Cc52e42b3eb63495ed28708d881910b6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401807671941922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YiZLS6kKMqe58vPsJFYIfA3nVICc3G44E6bziD3cC94%3D&reserved=0) > > > > Is it possible for the new table to express that an IOMMU covers all > PCI segments? This could help support scenarios where: > > > > 1. Devices are dynamically assigned to guests during runtime 2. > Devices in the same guests are assigned to different segments. This is possible with the current descriptor, assuming the PCI segments are static. The platform can provide a PCI Range Node for each segment, with a BDF range 0 - 0xffff. For example a table could describe: * PCI Range Node * PCI Segment: 0 * BDF start: 0 * BDF end: 0xffff * Endpoint start: 0 * Output node: &viommu * PCI Range Node * PCI Segment: 1 * BDF start: 0 * BDF end: 0xffff * Endpoint start: 0x10000 * Output node: &viommu * viommu Node Then the IOMMU covers all PCI devices on the two segments. To identify a device when configuring DMA translation, the IOMMU driver builds a 32-bit endpoint ID = Endpoint start + BDF. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2020-11-05 22:05 ` [EXTERNAL] " Yinghan Yang via iommu @ 2020-11-06 13:57 ` Jean-Philippe Brucker 2020-12-03 22:21 ` Yinghan Yang via iommu 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2020-11-06 13:57 UTC (permalink / raw) To: Yinghan Yang Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, ahs3 Hi Yinghan, On Thu, Nov 05, 2020 at 10:05:28PM +0000, Yinghan Yang wrote: > Thank you for the clarifications. In cases where a large range of PCI segments may be assigned to guest, would it make sense to describe this configuration as base + count. Currently, one would have to describe them individually. Yes, I've been wondering whether that would be useful. It would also allow hotplugging new segments, if that's ever needed. It requires changing the enumeration rule that derives an endpoint ID from segment + BDF number. First, when describing a range of segments, are BFD start and end still valid? Do they only apply to first and last segment respectively? To keep things simple I think BDF start/end should keep the same meaning: valid regardless of segment range, and apply to all segments in the range. So the new PCI Range node could be: Field Length Offset Description ------------------------------------------------------------------------------- Type 1 0 1 – PCI range Reserved 1 1 0. Length 2 2 Length of the node in bytes. Endpoint start 4 4 First endpoint ID. PCI Segment start 2 8 First PCI Segment number in the range. PCI Segment end 2 10 Last PCI Segment number in the range. PCI BDF start 2 12 First Bus-Device-Function number in the range. PCI BDF end 2 14 Last Bus-Device-Function number in the range. Output node 2 16 Offset from the start of the table to the next translation element. Reserved 6 18 0. A PCI device is affected by the node if its segment is in [Segment start, Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will be: ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start Does that sound OK? Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [EXTERNAL] Re: Question regarding VIOT proposal 2020-11-06 13:57 ` Jean-Philippe Brucker @ 2020-12-03 22:21 ` Yinghan Yang via iommu 2020-12-03 23:01 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Yinghan Yang via iommu @ 2020-12-03 22:21 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, ahs3 Hi Jean, I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? Other than that, the proposal looks good to go. Thanks, Yinghan -----Original Message----- From: Jean-Philippe Brucker <jean-philippe@linaro.org> Sent: Friday, November 6, 2020 5:58 AM To: Yinghan Yang <Yinghan.Yang@microsoft.com> Cc: iommu@lists.linux-foundation.org; Alexander Grest <Alexander.Grest@microsoft.com>; eric.auger@redhat.com; joro@8bytes.org; kevin.tian@intel.com; lorenzo.pieralisi@arm.com; mst@redhat.com; Boeuf, Sebastien <sebastien.boeuf@intel.com>; ahs3@redhat.com Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal Hi Yinghan, On Thu, Nov 05, 2020 at 10:05:28PM +0000, Yinghan Yang wrote: > Thank you for the clarifications. In cases where a large range of PCI segments may be assigned to guest, would it make sense to describe this configuration as base + count. Currently, one would have to describe them individually. Yes, I've been wondering whether that would be useful. It would also allow hotplugging new segments, if that's ever needed. It requires changing the enumeration rule that derives an endpoint ID from segment + BDF number. First, when describing a range of segments, are BFD start and end still valid? Do they only apply to first and last segment respectively? To keep things simple I think BDF start/end should keep the same meaning: valid regardless of segment range, and apply to all segments in the range. So the new PCI Range node could be: Field Length Offset Description ------------------------------------------------------------------------------- Type 1 0 1 – PCI range Reserved 1 1 0. Length 2 2 Length of the node in bytes. Endpoint start 4 4 First endpoint ID. PCI Segment start 2 8 First PCI Segment number in the range. PCI Segment end 2 10 Last PCI Segment number in the range. PCI BDF start 2 12 First Bus-Device-Function number in the range. PCI BDF end 2 14 Last Bus-Device-Function number in the range. Output node 2 16 Offset from the start of the table to the next translation element. Reserved 6 18 0. A PCI device is affected by the node if its segment is in [Segment start, Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will be: ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start Does that sound OK? Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2020-12-03 22:21 ` Yinghan Yang via iommu @ 2020-12-03 23:01 ` Al Stone 2020-12-04 18:09 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Al Stone @ 2020-12-03 23:01 UTC (permalink / raw) To: Yinghan Yang Cc: Jean-Philippe Brucker, kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest On 03 Dec 2020 22:21, Yinghan Yang wrote: > Hi Jean, > > I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? > > Other than that, the proposal looks good to go. > > Thanks, > Yinghan Jean, were you going to update your existing doc first? If you do that, then I can cut and paste the changes into the existing ASWG proposal. Or do you need to send out an RFC to the mailing list first and finalize it there? Thanks for all the help. > -----Original Message----- > From: Jean-Philippe Brucker <jean-philippe@linaro.org> > Sent: Friday, November 6, 2020 5:58 AM > To: Yinghan Yang <Yinghan.Yang@microsoft.com> > Cc: iommu@lists.linux-foundation.org; Alexander Grest <Alexander.Grest@microsoft.com>; eric.auger@redhat.com; joro@8bytes.org; kevin.tian@intel.com; lorenzo.pieralisi@arm.com; mst@redhat.com; Boeuf, Sebastien <sebastien.boeuf@intel.com>; ahs3@redhat.com > Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal > > Hi Yinghan, > > On Thu, Nov 05, 2020 at 10:05:28PM +0000, Yinghan Yang wrote: > > Thank you for the clarifications. In cases where a large range of PCI segments may be assigned to guest, would it make sense to describe this configuration as base + count. Currently, one would have to describe them individually. > > Yes, I've been wondering whether that would be useful. It would also allow hotplugging new segments, if that's ever needed. It requires changing the enumeration rule that derives an endpoint ID from segment + BDF number. > > First, when describing a range of segments, are BFD start and end still valid? Do they only apply to first and last segment respectively? To keep things simple I think BDF start/end should keep the same meaning: > valid regardless of segment range, and apply to all segments in the range. > > So the new PCI Range node could be: > > Field Length Offset Description > ------------------------------------------------------------------------------- > Type 1 0 1 – PCI range > Reserved 1 1 0. > Length 2 2 Length of the node in bytes. > Endpoint start 4 4 First endpoint ID. > PCI Segment start 2 8 First PCI Segment number in the range. > PCI Segment end 2 10 Last PCI Segment number in the range. > PCI BDF start 2 12 First Bus-Device-Function number in the range. > PCI BDF end 2 14 Last Bus-Device-Function number in the range. > Output node 2 16 Offset from the start of the table to the next translation element. > Reserved 6 18 0. > > A PCI device is affected by the node if its segment is in [Segment start, Segment end], and if its BDF is in [BPF start, BDF end]. Its endpoint ID will be: > > ((Segment - Segment start) << 16) + BDF - BDF start + Endpoint start > > Does that sound OK? > > Thanks, > Jean > -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2020-12-03 23:01 ` Al Stone @ 2020-12-04 18:09 ` Jean-Philippe Brucker 2020-12-04 18:15 ` Yinghan Yang via iommu 2020-12-04 20:18 ` Al Stone 0 siblings, 2 replies; 18+ messages in thread From: Jean-Philippe Brucker @ 2020-12-04 18:09 UTC (permalink / raw) To: Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang Hi, On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > Hi Jean, > > > > I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? > > > > Other than that, the proposal looks good to go. Thanks for the feedback, I made the change > > > > Thanks, > > Yinghan > > Jean, were you going to update your existing doc first? If you > do that, then I can cut and paste the changes into the existing > ASWG proposal. Or do you need to send out an RFC to the mailing > list first and finalize it there? I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf You can incorporate it into the ASWG proposal. Changes since v8: * One typo (s/programing/programming/) * Modified the PCI Range node to include a segment range. I also updated the Linux and QEMU implementations on branch virtio-iommu/devel in https://jpbrucker.net/git/linux/ and https://jpbrucker.net/git/qemu/ Thanks again for helping with this Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [EXTERNAL] Re: Question regarding VIOT proposal 2020-12-04 18:09 ` Jean-Philippe Brucker @ 2020-12-04 18:15 ` Yinghan Yang via iommu 2020-12-04 20:18 ` Al Stone 1 sibling, 0 replies; 18+ messages in thread From: Yinghan Yang via iommu @ 2020-12-04 18:15 UTC (permalink / raw) To: Jean-Philippe Brucker, Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest Thank you Jean. Yinghan -----Original Message----- From: Jean-Philippe Brucker <jean-philippe@linaro.org> Sent: Friday, December 4, 2020 10:09 AM To: Al Stone <ahs3@redhat.com> Cc: Yinghan Yang <Yinghan.Yang@microsoft.com>; iommu@lists.linux-foundation.org; Alexander Grest <Alexander.Grest@microsoft.com>; eric.auger@redhat.com; joro@8bytes.org; kevin.tian@intel.com; lorenzo.pieralisi@arm.com; mst@redhat.com; Boeuf, Sebastien <sebastien.boeuf@intel.com> Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal Hi, On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > Hi Jean, > > > > I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? > > > > Other than that, the proposal looks good to go. Thanks for the feedback, I made the change > > > > Thanks, > > Yinghan > > Jean, were you going to update your existing doc first? If you do > that, then I can cut and paste the changes into the existing ASWG > proposal. Or do you need to send out an RFC to the mailing list first > and finalize it there? I updated the doc: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fvirtio-iommu%2Fviot%2Fviot-v9.pdf&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uB0xVHvFdF1wkb2D4KJFW8JMGNtiT3tAsoNVU%2FdLlLA%3D&reserved=0 You can incorporate it into the ASWG proposal. Changes since v8: * One typo (s/programing/programming/) * Modified the PCI Range node to include a segment range. I also updated the Linux and QEMU implementations on branch virtio-iommu/devel in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fgit%2Flinux%2F&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8OS6A%2Bw1r77hiWIhUWGiUU1rZTXh0Qmx%2Fu7LzIIOalo%3D&reserved=0 and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fgit%2Fqemu%2F&data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qAX7dTxzkA%2FcqUg2urWipPv%2BCdu5yxuWGt3ndBYlQKU%3D&reserved=0 Thanks again for helping with this Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2020-12-04 18:09 ` Jean-Philippe Brucker 2020-12-04 18:15 ` Yinghan Yang via iommu @ 2020-12-04 20:18 ` Al Stone 2021-02-02 9:17 ` Jean-Philippe Brucker 1 sibling, 1 reply; 18+ messages in thread From: Al Stone @ 2020-12-04 20:18 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 04 Dec 2020 19:09, Jean-Philippe Brucker wrote: > Hi, > > On Thu, Dec 03, 2020 at 04:01:27PM -0700, Al Stone wrote: > > On 03 Dec 2020 22:21, Yinghan Yang wrote: > > > Hi Jean, > > > > > > I'm sorry for the delayed response. I think the new "PCI range node" description makes sense. Could you please make this change in the proposal? > > > > > > Other than that, the proposal looks good to go. > > Thanks for the feedback, I made the change > > > > > > > Thanks, > > > Yinghan > > > > Jean, were you going to update your existing doc first? If you > > do that, then I can cut and paste the changes into the existing > > ASWG proposal. Or do you need to send out an RFC to the mailing > > list first and finalize it there? > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > You can incorporate it into the ASWG proposal. > Changes since v8: > * One typo (s/programing/programming/) > * Modified the PCI Range node to include a segment range. > > I also updated the Linux and QEMU implementations on branch > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > https://jpbrucker.net/git/qemu/ > > Thanks again for helping with this > > Jean Perfect. Thanks. I'll update the ASWG info right away. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2020-12-04 20:18 ` Al Stone @ 2021-02-02 9:17 ` Jean-Philippe Brucker 2021-02-02 20:27 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2021-02-02 9:17 UTC (permalink / raw) To: Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang Hi Al, On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > You can incorporate it into the ASWG proposal. > > Changes since v8: > > * One typo (s/programing/programming/) > > * Modified the PCI Range node to include a segment range. > > > > I also updated the Linux and QEMU implementations on branch > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > https://jpbrucker.net/git/qemu/ > > > > Thanks again for helping with this > > > > Jean > > Perfect. Thanks. I'll update the ASWG info right away. Has there been any more feedback on the VIOT specification? I'm wondering when we can start upstreaming support for it. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-02 9:17 ` Jean-Philippe Brucker @ 2021-02-02 20:27 ` Al Stone 2021-02-03 8:46 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Al Stone @ 2021-02-02 20:27 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > Hi Al, > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > You can incorporate it into the ASWG proposal. > > > Changes since v8: > > > * One typo (s/programing/programming/) > > > * Modified the PCI Range node to include a segment range. > > > > > > I also updated the Linux and QEMU implementations on branch > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > https://jpbrucker.net/git/qemu/ > > > > > > Thanks again for helping with this > > > > > > Jean > > > > Perfect. Thanks. I'll update the ASWG info right away. > > Has there been any more feedback on the VIOT specification? I'm wondering > when we can start upstreaming support for it. > > Thanks, > Jean Ah, sorry, Jean. I meant to get back to you sooner. My apologies. The latest version that resulted from the discussion with Yinghan of Microsoft is the one in front the ASWG; I think if you upstream that version, it should be identical to the spec when it is next published (post ACPI 6.4). The process is: (1) propose the change, (2) review it in committee, (3) give people more time to think about it, then (4) have a finale vote. We've been iterating over (1), (2) and (3). Since there was no new discussion at the last meeting, we should have the final vote on this (4) in the next meeting. I had hoped we could do that last week but the meeting was canceled at the last minute. I hope to have the final vote this Thursday and will let you know as soon as it has been decided. My apologies for the delays; getting things done by committee always takes a bazillion times longer than one would think. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-02 20:27 ` Al Stone @ 2021-02-03 8:46 ` Jean-Philippe Brucker 2021-02-04 20:25 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2021-02-03 8:46 UTC (permalink / raw) To: Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > Hi Al, > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > You can incorporate it into the ASWG proposal. > > > > Changes since v8: > > > > * One typo (s/programing/programming/) > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > Thanks again for helping with this > > > > > > > > Jean > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > when we can start upstreaming support for it. > > > > Thanks, > > Jean > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > The latest version that resulted from the discussion with Yinghan of > Microsoft is the one in front the ASWG; I think if you upstream that > version, it should be identical to the spec when it is next published > (post ACPI 6.4). > > The process is: (1) propose the change, (2) review it in committee, > (3) give people more time to think about it, then (4) have a finale > vote. We've been iterating over (1), (2) and (3). Since there was > no new discussion at the last meeting, we should have the final vote > on this (4) in the next meeting. I had hoped we could do that last > week but the meeting was canceled at the last minute. I hope to have > the final vote this Thursday and will let you know as soon as it has > been decided. > > My apologies for the delays; getting things done by committee always > takes a bazillion times longer than one would think. No worries, thanks a lot for the update! Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-03 8:46 ` Jean-Philippe Brucker @ 2021-02-04 20:25 ` Al Stone 2021-02-16 21:31 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Al Stone @ 2021-02-04 20:25 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 03 Feb 2021 09:46, Jean-Philippe Brucker wrote: > On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > > Hi Al, > > > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > > You can incorporate it into the ASWG proposal. > > > > > Changes since v8: > > > > > * One typo (s/programing/programming/) > > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > > > Thanks again for helping with this > > > > > > > > > > Jean > > > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > > when we can start upstreaming support for it. > > > > > > Thanks, > > > Jean > > > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > > > The latest version that resulted from the discussion with Yinghan of > > Microsoft is the one in front the ASWG; I think if you upstream that > > version, it should be identical to the spec when it is next published > > (post ACPI 6.4). > > > > The process is: (1) propose the change, (2) review it in committee, > > (3) give people more time to think about it, then (4) have a finale > > vote. We've been iterating over (1), (2) and (3). Since there was > > no new discussion at the last meeting, we should have the final vote > > on this (4) in the next meeting. I had hoped we could do that last > > week but the meeting was canceled at the last minute. I hope to have > > the final vote this Thursday and will let you know as soon as it has > > been decided. > > > > My apologies for the delays; getting things done by committee always > > takes a bazillion times longer than one would think. > > No worries, thanks a lot for the update! > > Thanks, > Jean Sigh. Just got a note that today's meeting has been canceled :(. So, next week for the final vote. OTOH, there have been no comments of any sort on the proposal -- and silence is good, in this case. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-04 20:25 ` Al Stone @ 2021-02-16 21:31 ` Al Stone 2021-02-17 9:37 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Al Stone @ 2021-02-16 21:31 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 04 Feb 2021 13:25, Al Stone wrote: > On 03 Feb 2021 09:46, Jean-Philippe Brucker wrote: > > On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > > > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > > > Hi Al, > > > > > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > > > You can incorporate it into the ASWG proposal. > > > > > > Changes since v8: > > > > > > * One typo (s/programing/programming/) > > > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > > > > > Thanks again for helping with this > > > > > > > > > > > > Jean > > > > > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > > > when we can start upstreaming support for it. > > > > > > > > Thanks, > > > > Jean > > > > > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > > > > > The latest version that resulted from the discussion with Yinghan of > > > Microsoft is the one in front the ASWG; I think if you upstream that > > > version, it should be identical to the spec when it is next published > > > (post ACPI 6.4). > > > > > > The process is: (1) propose the change, (2) review it in committee, > > > (3) give people more time to think about it, then (4) have a finale > > > vote. We've been iterating over (1), (2) and (3). Since there was > > > no new discussion at the last meeting, we should have the final vote > > > on this (4) in the next meeting. I had hoped we could do that last > > > week but the meeting was canceled at the last minute. I hope to have > > > the final vote this Thursday and will let you know as soon as it has > > > been decided. > > > > > > My apologies for the delays; getting things done by committee always > > > takes a bazillion times longer than one would think. > > > > No worries, thanks a lot for the update! > > > > Thanks, > > Jean > > Sigh. Just got a note that today's meeting has been canceled :(. > > So, next week for the final vote. OTOH, there have been no comments > of any sort on the proposal -- and silence is good, in this case. Would you believe last week's meeting was canceled, too? Not sure why the chair/co-chair are doing this but I'm finding it a little frustrating. We'll try again this week ... again, apologies for the delays. I'd recommend going with the last version posted just so progress can be made. The spec can always be fixed later. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-16 21:31 ` Al Stone @ 2021-02-17 9:37 ` Jean-Philippe Brucker 2021-02-18 23:39 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2021-02-17 9:37 UTC (permalink / raw) To: Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On Tue, Feb 16, 2021 at 02:31:03PM -0700, Al Stone wrote: > Would you believe last week's meeting was canceled, too? Not sure > why the chair/co-chair are doing this but I'm finding it a little > frustrating. > > We'll try again this week ... again, apologies for the delays. I'd > recommend going with the last version posted just so progress can be > made. The spec can always be fixed later. Thanks, I'll send the acpica changes for review and follow with QEMU and Linux patches. These things also take time so I might as well start in parallel. Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-17 9:37 ` Jean-Philippe Brucker @ 2021-02-18 23:39 ` Al Stone 2021-02-19 11:24 ` Jean-Philippe Brucker 0 siblings, 1 reply; 18+ messages in thread From: Al Stone @ 2021-02-18 23:39 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 17 Feb 2021 10:37, Jean-Philippe Brucker wrote: > On Tue, Feb 16, 2021 at 02:31:03PM -0700, Al Stone wrote: > > Would you believe last week's meeting was canceled, too? Not sure > > why the chair/co-chair are doing this but I'm finding it a little > > frustrating. > > > > We'll try again this week ... again, apologies for the delays. I'd > > recommend going with the last version posted just so progress can be > > made. The spec can always be fixed later. > > Thanks, I'll send the acpica changes for review and follow with QEMU and > Linux patches. These things also take time so I might as well start in > parallel. > > Thanks, > Jean As of today, the proposal has been approved for inclusion in the next release of the ACPI spec (whatever version gets released post the 6.4 version that just came out). Congratulations ?!? :) And thanks to all for their patience during this process. You now have the dubious disctinction of being the very first table added to the spec that _started_ as open source. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-18 23:39 ` Al Stone @ 2021-02-19 11:24 ` Jean-Philippe Brucker 2021-02-19 17:35 ` Al Stone 0 siblings, 1 reply; 18+ messages in thread From: Jean-Philippe Brucker @ 2021-02-19 11:24 UTC (permalink / raw) To: Al Stone Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On Thu, Feb 18, 2021 at 04:39:43PM -0700, Al Stone wrote: > As of today, the proposal has been approved for inclusion in the next > release of the ACPI spec (whatever version gets released post the 6.4 > version that just came out). > > Congratulations ?!? :) > > And thanks to all for their patience during this process. You now > have the dubious disctinction of being the very first table added > to the spec that _started_ as open source. That is great news! Thanks again for your help with this :) Just to confirm, we don't need to wait for the release of the 6.5 version of the spec before upstreaming support for the table? Another question that might come up at some point, is how to add new subtables. Is the process documented somewhere? For the moment I sent a -poorly numbered- pull request for acpica: https://github.com/acpica/acpica/pull/666 Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [EXTERNAL] Re: Question regarding VIOT proposal 2021-02-19 11:24 ` Jean-Philippe Brucker @ 2021-02-19 17:35 ` Al Stone 0 siblings, 0 replies; 18+ messages in thread From: Al Stone @ 2021-02-19 17:35 UTC (permalink / raw) To: Jean-Philippe Brucker Cc: kevin.tian, mst, iommu, Boeuf, Sebastien, Alexander Grest, Yinghan Yang On 19 Feb 2021 12:24, Jean-Philippe Brucker wrote: > On Thu, Feb 18, 2021 at 04:39:43PM -0700, Al Stone wrote: > > As of today, the proposal has been approved for inclusion in the next > > release of the ACPI spec (whatever version gets released post the 6.4 > > version that just came out). > > > > Congratulations ?!? :) > > > > And thanks to all for their patience during this process. You now > > have the dubious disctinction of being the very first table added > > to the spec that _started_ as open source. > > That is great news! Thanks again for your help with this :) > > Just to confirm, we don't need to wait for the release of the 6.5 version > of the spec before upstreaming support for the table? Correct. This is why the UEFI community-first process exists -- so the work can be done in the open instead of having to wait for the next spec release. > Another question that might come up at some point, is how to add new > subtables. Is the process documented somewhere? We would do essentially the same thing: there would be a discussion on a list somewhere, a conclusion would be drawn, and an ECR put together to send to the ASWG group (any UEFI member can do that, like Yinghan, for example). All discussion of changes would occur in the open -- ASWG is really just monitoring progress in these cases. Once it is clear that the proposed change is stable and essentially finalized by the community, there would be a final vote in the ASWG on whether to include it or not. > For the moment I sent a -poorly numbered- pull request for acpica: > https://github.com/acpica/acpica/pull/666 That's hilarious :-D. I'm sure it will be just fine :-).... I'll put a tag on that PR to track it. > Thanks, > Jean > -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@redhat.com ----------------------------------- _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-02-19 17:36 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-05 0:13 Question regarding VIOT proposal Yinghan Yang via iommu 2020-11-05 13:45 ` Jean-Philippe Brucker 2020-11-05 22:05 ` [EXTERNAL] " Yinghan Yang via iommu 2020-11-06 13:57 ` Jean-Philippe Brucker 2020-12-03 22:21 ` Yinghan Yang via iommu 2020-12-03 23:01 ` Al Stone 2020-12-04 18:09 ` Jean-Philippe Brucker 2020-12-04 18:15 ` Yinghan Yang via iommu 2020-12-04 20:18 ` Al Stone 2021-02-02 9:17 ` Jean-Philippe Brucker 2021-02-02 20:27 ` Al Stone 2021-02-03 8:46 ` Jean-Philippe Brucker 2021-02-04 20:25 ` Al Stone 2021-02-16 21:31 ` Al Stone 2021-02-17 9:37 ` Jean-Philippe Brucker 2021-02-18 23:39 ` Al Stone 2021-02-19 11:24 ` Jean-Philippe Brucker 2021-02-19 17:35 ` Al Stone
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 NNTP newsgroup(s).