Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
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 > Sent: Friday, November 6, 2020 5:58 AM > To: Yinghan Yang > Cc: iommu@lists.linux-foundation.org; Alexander Grest > ; eric.au...@redhat.com; j...@8bytes.org; > kevin.t...@intel.com; lorenzo.pieral...@arm.com; m...@redhat.com; Boeuf, > Sebastien ; a...@redhat.com > Subject: Re: [EXTERNAL] Re: Question regarding VIOT proposal > > Hi Yinghan, > > On Thu, Nov 05, 2020 at 10:05:28PM +, 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 > --- > Type1 0 1 – PCI range > Reserved1 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. > Reserved6 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. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/6] Add virtio-iommu built-in topology
On 04 Nov 2020 10:33, Jean-Philippe Brucker wrote: > Hi Al, > > On Tue, Nov 03, 2020 at 01:09:04PM -0700, Al Stone wrote: > > So, there are some questions about the VIOT definition and I just > > don't know enough to be able to answer them. One of the ASWG members > > is trying to understand the semantics behind the subtables. > > Thanks for the update. We dropped subtables a few versions ago, though, do > you have the latest v8? > https://jpbrucker.net/virtio-iommu/viot/viot-v8.pdf Sorry, I confused some terminology: what are called the Node structures are implemented as "subtables" in the ACPI reference implementation (ACPICA). But yes, I've proposed the v8 version. > > Is there a particular set of people, or mailing lists, that I can > > point to to get the questions answered? Ideally it would be one > > of the public lists where it has already been discussed, but an > > individual would be fine, too. No changes have been proposed, just > > some questions asked. > > For a public list, I suggest iommu@lists.linux-foundation.org if we should > pick only one (otherwise add virtualizat...@lists.linux-foundation.org and > virtio-...@lists.oasis-open.org). I'm happy to answer any question, and > the folks on here are a good set to Cc: > > eric.au...@redhat.com > jean-phili...@linaro.org > j...@8bytes.org > kevin.t...@intel.com > lorenzo.pieral...@arm.com > m...@redhat.com > sebastien.bo...@intel.com > > Thanks, > Jean > Merci, Jean-Philippe :). I'll point the individual at you and the iommu mailing list, and the CCs. Sadly, I did not write down the full question, nor the person's name (from Microsoft, possibly?) and now seem to have completely forgotten both (it's been a long few months...). If I can find something in the meeting minutes, I'll pass that on. Thanks again for everyone's patience. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/6] Add virtio-iommu built-in topology
On 06 Oct 2020 17:23, Auger Eric wrote: > Hello Al, > > On 10/2/20 8:23 PM, Al Stone wrote: > > On 24 Sep 2020 11:54, Auger Eric wrote: > >> Hi, > >> > >> Adding Al in the loop > >> > >> On 9/24/20 11:38 AM, Michael S. Tsirkin wrote: > >>> On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote: > >>>> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote: > >>>>> OK so this looks good. Can you pls repost with the minor tweak > >>>>> suggested and all acks included, and I will queue this? > >>>> > >>>> My NACK still stands, as long as a few questions are open: > >>>> > >>>> 1) The format used here will be the same as in the ACPI table? I > >>>> think the answer to this questions must be Yes, so this leads > >>>> to the real question: > >>> > >>> I am not sure it's a must. > >>> We can always tweak the parser if there are slight differences > >>> between ACPI and virtio formats. > >>> > >>> But we do want the virtio format used here to be approved by the virtio > >>> TC, so it won't change. > >>> > >>> Eric, Jean-Philippe, does one of you intend to create a github issue > >>> and request a ballot for the TC? It's been posted end of August with no > >>> changes ... > >> Jean-Philippe, would you? > >>> > >>>> 2) Has the ACPI table format stabalized already? If and only if > >>>> the answer is Yes I will Ack these patches. We don't need to > >>>> wait until the ACPI table format is published in a > >>>> specification update, but at least some certainty that it > >>>> will not change in incompatible ways anymore is needed. > >>>> > >> > >> Al, do you have any news about the the VIOT definition submission to > >> the UEFI ASWG? > >> > >> Thank you in advance > >> > >> Best Regards > >> > >> Eric > > > > A follow-up to my earlier post > > > > Hearing no objection, I've submitted the VIOT table description to > > the ASWG for consideration under what they call the "code first" > > process. The "first reading" -- a brief discussion on what the > > table is and why we would like to add it -- was held yesterday. > > No concerns have been raised as yet. Given the discussions that > > have already occurred, I don't expect any, either. I have been > > wrong at least once before, however. > > > > At this point, ASWG will revisit the request to add VIOT each > > week. If there have been no comments in the prior week, and no > > further discussion during the meeting, then a vote will be taken. > > Otherwise, there will be discussion and we try again the next > > week. > > > > The ASWG was also told that the likelihood of this definition of > > the table changing is pretty low, and that it has been thought out > > pretty well already. ASWG's consideration will therefore start > > from the assumption that it would be best _not_ to make changes. > > > > So, I'll let you know what happens next week. > > Thank you very much for the updates and for your support backing the > proposal in the best delays. > > Best Regards > > Eric So, there are some questions about the VIOT definition and I just don't know enough to be able to answer them. One of the ASWG members is trying to understand the semantics behind the subtables. Is there a particular set of people, or mailing lists, that I can point to to get the questions answered? Ideally it would be one of the public lists where it has already been discussed, but an individual would be fine, too. No changes have been proposed, just some questions asked. Thanks. > > > >> > >>> > >>> Not that I know, but I don't see why it's a must. > >>> > >>>> So what progress has been made with the ACPI table specification, is it > >>>> just a matter of time to get it approved or are there concerns? > >>>> > >>>> Regards, > >>>> > >>>> Joerg > >>> > >> > > > -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/6] Add virtio-iommu built-in topology
On 24 Sep 2020 11:54, Auger Eric wrote: > Hi, > > Adding Al in the loop > > On 9/24/20 11:38 AM, Michael S. Tsirkin wrote: > > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote: > >> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote: > >>> OK so this looks good. Can you pls repost with the minor tweak > >>> suggested and all acks included, and I will queue this? > >> > >> My NACK still stands, as long as a few questions are open: > >> > >>1) The format used here will be the same as in the ACPI table? I > >> think the answer to this questions must be Yes, so this leads > >> to the real question: > > > > I am not sure it's a must. > > We can always tweak the parser if there are slight differences > > between ACPI and virtio formats. > > > > But we do want the virtio format used here to be approved by the virtio > > TC, so it won't change. > > > > Eric, Jean-Philippe, does one of you intend to create a github issue > > and request a ballot for the TC? It's been posted end of August with no > > changes ... > Jean-Philippe, would you? > > > >>2) Has the ACPI table format stabalized already? If and only if > >> the answer is Yes I will Ack these patches. We don't need to > >> wait until the ACPI table format is published in a > >> specification update, but at least some certainty that it > >> will not change in incompatible ways anymore is needed. > >> > > Al, do you have any news about the the VIOT definition submission to > the UEFI ASWG? > > Thank you in advance > > Best Regards > > Eric A follow-up to my earlier post Hearing no objection, I've submitted the VIOT table description to the ASWG for consideration under what they call the "code first" process. The "first reading" -- a brief discussion on what the table is and why we would like to add it -- was held yesterday. No concerns have been raised as yet. Given the discussions that have already occurred, I don't expect any, either. I have been wrong at least once before, however. At this point, ASWG will revisit the request to add VIOT each week. If there have been no comments in the prior week, and no further discussion during the meeting, then a vote will be taken. Otherwise, there will be discussion and we try again the next week. The ASWG was also told that the likelihood of this definition of the table changing is pretty low, and that it has been thought out pretty well already. ASWG's consideration will therefore start from the assumption that it would be best _not_ to make changes. So, I'll let you know what happens next week. > > > > > Not that I know, but I don't see why it's a must. > > > >> So what progress has been made with the ACPI table specification, is it > >> just a matter of time to get it approved or are there concerns? > >> > >> Regards, > >> > >>Joerg > > > -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/6] Add virtio-iommu built-in topology
On 24 Sep 2020 11:54, Auger Eric wrote: > Hi, > > Adding Al in the loop > > On 9/24/20 11:38 AM, Michael S. Tsirkin wrote: > > On Thu, Sep 24, 2020 at 11:21:29AM +0200, Joerg Roedel wrote: > >> On Thu, Sep 24, 2020 at 05:00:35AM -0400, Michael S. Tsirkin wrote: > >>> OK so this looks good. Can you pls repost with the minor tweak > >>> suggested and all acks included, and I will queue this? > >> > >> My NACK still stands, as long as a few questions are open: > >> > >>1) The format used here will be the same as in the ACPI table? I > >> think the answer to this questions must be Yes, so this leads > >> to the real question: > > > > I am not sure it's a must. > > We can always tweak the parser if there are slight differences > > between ACPI and virtio formats. > > > > But we do want the virtio format used here to be approved by the virtio > > TC, so it won't change. As long as we can convey the same content to the UEFI ASWG, we're fine. Format/syntax of the submittal is not absolutely critical though it does need translating to what the ASWG expects (see https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process for details -- basically a bugzilla with markdown text. > > Eric, Jean-Philippe, does one of you intend to create a github issue > > and request a ballot for the TC? It's been posted end of August with no > > changes ... > Jean-Philippe, would you? > > > >>2) Has the ACPI table format stabalized already? If and only if > >> the answer is Yes I will Ack these patches. We don't need to > >> wait until the ACPI table format is published in a > >> specification update, but at least some certainty that it > >> will not change in incompatible ways anymore is needed. > >> > > Al, do you have any news about the the VIOT definition submission to > the UEFI ASWG? > > Thank you in advance > > Best Regards > > Eric > > > > > > Not that I know, but I don't see why it's a must. > > > >> So what progress has been made with the ACPI table specification, is it > >> just a matter of time to get it approved or are there concerns? > >> > >> Regards, > >> > >>Joerg My apologies for the delay. No excuses, just not enough hours in the day. I will make the proper submission to the ASWG later today to have it considered later this week -- I had quite a bit of confusion around how the process is supposed to work but I think we've got that cleared up (see the link noted above). The content of the table appears to be in really good shape. Will it change? Possibly, but my expectation is that it will be minor details, nothing wholesale; having the table in use in code tends to act as a pretty fierce restraint on making changes (there's a lot of precedent for that in ASWG). The biggest question is: are there any objections to having this table description licensed under Creative Commons Attribution International 4.0 (see https://spdx.org/licenses/CC-BY-4.0.html)? This is just for the table description, not the code. If there are, that needs to be cleared up first. If not, then the submittal this week should happen. Once submitted to ASWG, there is a very slim chance it will end up in ACPI 6.4 which is mostly done now -- very, very slim, but stranger things have happened. Most likely, once approved it would be in ACPI 6.5, sometime in 2021. I'll post the link to the submittal as soon as I can. Again, my apologies for the delays; approval in the spec can proceed pretty much independent of the implementation, and vice versa. That's really the whole point of this new process with the UEFI Forum. -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
