Question regarding VIOT proposal

Question regarding VIOT proposal

[Yinghan Yang via iommu]

[-- 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

Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

RE: [EXTERNAL] Re: Question regarding VIOT proposal

[Yinghan Yang via iommu]

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&amp;data=04%7C01%7CYinghan.Yang%40microsoft.com%7Cc52e42b3eb63495ed28708d881910b6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401807671941922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YiZLS6kKMqe58vPsJFYIfA3nVICc3G44E6bziD3cC94%3D&amp;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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

RE: [EXTERNAL] Re: Question regarding VIOT proposal

[Yinghan Yang via iommu]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

RE: [EXTERNAL] Re: Question regarding VIOT proposal

[Yinghan Yang via iommu]

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&amp;data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uB0xVHvFdF1wkb2D4KJFW8JMGNtiT3tAsoNVU%2FdLlLA%3D&amp;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&amp;data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=8OS6A%2Bw1r77hiWIhUWGiUU1rZTXh0Qmx%2Fu7LzIIOalo%3D&amp;reserved=0 and
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjpbrucker.net%2Fgit%2Fqemu%2F&amp;data=04%7C01%7CYinghan.Yang%40microsoft.com%7C91f189f2a0814e6743c308d8987fc809%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637427022395762927%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qAX7dTxzkA%2FcqUg2urWipPv%2BCdu5yxuWGt3ndBYlQKU%3D&amp;reserved=0

Thanks again for helping with this

Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Jean-Philippe Brucker]

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

Re: [EXTERNAL] Re: Question regarding VIOT proposal

[Al Stone]

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