Re: [PATCH v3 0/6] Add virtio-iommu built-in topology

[Al Stone <ahs3@redhat.com>]

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.
ahs3@redhat.com
-----------------------------------