Michael S. Tsirkin
2020-Sep-24 09:38 UTC
[PATCH v3 0/6] Add virtio-iommu built-in topology
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 ...> 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. >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
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> > 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 >
On Thu, Sep 24, 2020 at 05:38:13AM -0400, 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.It is, having only one parser for the ACPI and MMIO descriptions was one of the selling points for MMIO in past discussions and I think it makes sense to keep them in sync.> We can always tweak the parser if there are slight differences > between ACPI and virtio formats.There is no guarantee that there only need to be "tweaks" until the ACPI table format is stablized. Regards, Joerg
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:> On Thu, Sep 24, 2020 at 05:38:13AM -0400, 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. > > It is, having only one parser for the ACPI and MMIO descriptions was one > of the selling points for MMIO in past discussions and I think it makes > sense to keep them in sync.So that requirement basically kills the "we have something to play with while the acpi table spec is in progress" argument. Also note that qemu microvm got acpi support meanwhile. Are there other cases where neither ACPI nor DT are available? take care, Gerd
Jean-Philippe Brucker
2020-Sep-24 10:29 UTC
[PATCH v3 0/6] Add virtio-iommu built-in topology
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:> On Thu, Sep 24, 2020 at 05:38:13AM -0400, 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. > > It is, having only one parser for the ACPI and MMIO descriptions was one > of the selling points for MMIO in past discussions and I think it makes > sense to keep them in sync.It's not possible to use exactly the same code for parsing. The access methods are different (need to deal with port-IO for built-in description on PCI, for example) and more importantly, the structure is different as well. The ACPI table needs nodes for virtio-iommu while the built-in description is contained in the virtio-iommu itself. So the endpoint nodes point to virtio-iommu node on ACPI, while they don't need a pointer on the built-in desc. I kept as much as possible common in structures and implementation, but in the end we still need about 200 unique lines on each side. Thanks, Jean> > > We can always tweak the parser if there are slight differences > > between ACPI and virtio formats. > > There is no guarantee that there only need to be "tweaks" until the > ACPI table format is stablized. > > Regards, > > Joerg >
Michael S. Tsirkin
2020-Sep-24 12:41 UTC
[PATCH v3 0/6] Add virtio-iommu built-in topology
On Thu, Sep 24, 2020 at 12:02:55PM +0200, Joerg Roedel wrote:> On Thu, Sep 24, 2020 at 05:38:13AM -0400, 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. > > It is, having only one parser for the ACPI and MMIO descriptions was one > of the selling points for MMIO in past discussions and I think it makes > sense to keep them in sync. > > > We can always tweak the parser if there are slight differences > > between ACPI and virtio formats. > > There is no guarantee that there only need to be "tweaks" until the > ACPI table format is stablized. > > Regards, > > JoergBut this has nothing to do with Linux. There is also no guarantee that the two committees will decide to use exactly the same format. Once one of them sets the format in stone, we can add support for that format to linux. If another one is playing nice and uses the same format, we can use the same parsers. If it doesn't linux will have to follow suit. -- MST