| Message ID | 20200821131540.2801801-1-jean-philippe@linaro.org |
|---|---|
| Headers | show |
| Series | Add virtio-iommu built-in topology | expand |
On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new vendor-agnostic table describing para-virtual topologies in a > minimal format. However some platforms don't use either ACPI or DT for > booting (for example microvm), and will need the alternative topology > description method proposed here. In addition, since the process to get > a new ACPI table will take a long time, this provides a boot method even > to ACPI-based platforms, if only temporarily for testing and > development. OK should I park this in next now? Seems appropriate ... > v3: > * Add patch 1 that moves virtio-iommu to a subfolder. > * Split the rest: > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > support. > * Patch 4 adds definitions. > * Patch 5 adds parser in topology.c. > * Address other comments. > > Linux and QEMU patches available at: > https://jpbrucker.net/git/linux virtio-iommu/devel > https://jpbrucker.net/git/qemu virtio-iommu/devel > > [spec] https://lists.oasis-open.org/archives/virtio-dev/202008/msg00067.html > [v2] https://lore.kernel.org/linux-iommu/20200228172537.377327-1-jean-philippe@linaro.org/ > [v1] https://lore.kernel.org/linux-iommu/20200214160413.1475396-1-jean-philippe@linaro.org/ > [rfc] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/ > > Jean-Philippe Brucker (6): > iommu/virtio: Move to drivers/iommu/virtio/ > iommu/virtio: Add topology helpers > PCI: Add DMA configuration for virtual platforms > iommu/virtio: Add topology definitions > iommu/virtio: Support topology description in config space > iommu/virtio: Enable x86 support > > drivers/iommu/Kconfig | 18 +- > drivers/iommu/Makefile | 3 +- > drivers/iommu/virtio/Makefile | 4 + > drivers/iommu/virtio/topology-helpers.h | 50 +++++ > include/linux/virt_iommu.h | 15 ++ > include/uapi/linux/virtio_iommu.h | 44 ++++ > drivers/iommu/virtio/topology-helpers.c | 196 ++++++++++++++++ > drivers/iommu/virtio/topology.c | 259 ++++++++++++++++++++++ > drivers/iommu/{ => virtio}/virtio-iommu.c | 4 + > drivers/pci/pci-driver.c | 5 + > MAINTAINERS | 3 +- > 11 files changed, 597 insertions(+), 4 deletions(-) > create mode 100644 drivers/iommu/virtio/Makefile > create mode 100644 drivers/iommu/virtio/topology-helpers.h > create mode 100644 include/linux/virt_iommu.h > create mode 100644 drivers/iommu/virtio/topology-helpers.c > create mode 100644 drivers/iommu/virtio/topology.c > rename drivers/iommu/{ => virtio}/virtio-iommu.c (99%) > > -- > 2.28.0 > > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Aug 26, 2020 at 09:26:02AM -0400, Michael S. Tsirkin wrote: > On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > > Add a topology description to the virtio-iommu driver and enable x86 > > platforms. > > > > Since [v2] we have made some progress on adding ACPI support for > > virtio-iommu, which is the preferred boot method on x86. It will be a > > new vendor-agnostic table describing para-virtual topologies in a > > minimal format. However some platforms don't use either ACPI or DT for > > booting (for example microvm), and will need the alternative topology > > description method proposed here. In addition, since the process to get > > a new ACPI table will take a long time, this provides a boot method even > > to ACPI-based platforms, if only temporarily for testing and > > development. > > OK should I park this in next now? Seems appropriate ... Yes that sounds like a good idea. It could uncover new bugs since there is more automated testing happening for x86. Thanks, Jean
Hi, On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new vendor-agnostic table describing para-virtual topologies in a > minimal format. However some platforms don't use either ACPI or DT for > booting (for example microvm), and will need the alternative topology > description method proposed here. In addition, since the process to get > a new ACPI table will take a long time, this provides a boot method even > to ACPI-based platforms, if only temporarily for testing and > development. > > v3: > * Add patch 1 that moves virtio-iommu to a subfolder. > * Split the rest: > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > support. > * Patch 4 adds definitions. > * Patch 5 adds parser in topology.c. > * Address other comments. > > Linux and QEMU patches available at: > https://jpbrucker.net/git/linux virtio-iommu/devel > https://jpbrucker.net/git/qemu virtio-iommu/devel I have tested that series with above QEMU branch on ARM with virtio-net and virtio-blk translated devices in non DT mode. It works for me: Tested-by: Eric Auger <eric.auger@redhat.com> Thanks Eric > > [spec] https://lists.oasis-open.org/archives/virtio-dev/202008/msg00067.html > [v2] https://lore.kernel.org/linux-iommu/20200228172537.377327-1-jean-philippe@linaro.org/ > [v1] https://lore.kernel.org/linux-iommu/20200214160413.1475396-1-jean-philippe@linaro.org/ > [rfc] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/ > > Jean-Philippe Brucker (6): > iommu/virtio: Move to drivers/iommu/virtio/ > iommu/virtio: Add topology helpers > PCI: Add DMA configuration for virtual platforms > iommu/virtio: Add topology definitions > iommu/virtio: Support topology description in config space > iommu/virtio: Enable x86 support > > drivers/iommu/Kconfig | 18 +- > drivers/iommu/Makefile | 3 +- > drivers/iommu/virtio/Makefile | 4 + > drivers/iommu/virtio/topology-helpers.h | 50 +++++ > include/linux/virt_iommu.h | 15 ++ > include/uapi/linux/virtio_iommu.h | 44 ++++ > drivers/iommu/virtio/topology-helpers.c | 196 ++++++++++++++++ > drivers/iommu/virtio/topology.c | 259 ++++++++++++++++++++++ > drivers/iommu/{ => virtio}/virtio-iommu.c | 4 + > drivers/pci/pci-driver.c | 5 + > MAINTAINERS | 3 +- > 11 files changed, 597 insertions(+), 4 deletions(-) > create mode 100644 drivers/iommu/virtio/Makefile > create mode 100644 drivers/iommu/virtio/topology-helpers.h > create mode 100644 include/linux/virt_iommu.h > create mode 100644 drivers/iommu/virtio/topology-helpers.c > create mode 100644 drivers/iommu/virtio/topology.c > rename drivers/iommu/{ => virtio}/virtio-iommu.c (99%) >
On Fri, Sep 04, 2020 at 06:24:12PM +0200, Auger Eric wrote: > Hi, > > On 8/21/20 3:15 PM, Jean-Philippe Brucker wrote: > > Add a topology description to the virtio-iommu driver and enable x86 > > platforms. > > > > Since [v2] we have made some progress on adding ACPI support for > > virtio-iommu, which is the preferred boot method on x86. It will be a > > new vendor-agnostic table describing para-virtual topologies in a > > minimal format. However some platforms don't use either ACPI or DT for > > booting (for example microvm), and will need the alternative topology > > description method proposed here. In addition, since the process to get > > a new ACPI table will take a long time, this provides a boot method even > > to ACPI-based platforms, if only temporarily for testing and > > development. > > > > v3: > > * Add patch 1 that moves virtio-iommu to a subfolder. > > * Split the rest: > > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > > support. > > * Patch 4 adds definitions. > > * Patch 5 adds parser in topology.c. > > * Address other comments. > > > > Linux and QEMU patches available at: > > https://jpbrucker.net/git/linux virtio-iommu/devel > > https://jpbrucker.net/git/qemu virtio-iommu/devel > I have tested that series with above QEMU branch on ARM with virtio-net > and virtio-blk translated devices in non DT mode. > > It works for me: > Tested-by: Eric Auger <eric.auger@redhat.com> > > Thanks > > Eric OK so this looks good. Can you pls repost with the minor tweak suggested and all acks included, and I will queue this? Thanks! > > > > [spec] https://lists.oasis-open.org/archives/virtio-dev/202008/msg00067.html > > [v2] https://lore.kernel.org/linux-iommu/20200228172537.377327-1-jean-philippe@linaro.org/ > > [v1] https://lore.kernel.org/linux-iommu/20200214160413.1475396-1-jean-philippe@linaro.org/ > > [rfc] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/ > > > > Jean-Philippe Brucker (6): > > iommu/virtio: Move to drivers/iommu/virtio/ > > iommu/virtio: Add topology helpers > > PCI: Add DMA configuration for virtual platforms > > iommu/virtio: Add topology definitions > > iommu/virtio: Support topology description in config space > > iommu/virtio: Enable x86 support > > > > drivers/iommu/Kconfig | 18 +- > > drivers/iommu/Makefile | 3 +- > > drivers/iommu/virtio/Makefile | 4 + > > drivers/iommu/virtio/topology-helpers.h | 50 +++++ > > include/linux/virt_iommu.h | 15 ++ > > include/uapi/linux/virtio_iommu.h | 44 ++++ > > drivers/iommu/virtio/topology-helpers.c | 196 ++++++++++++++++ > > drivers/iommu/virtio/topology.c | 259 ++++++++++++++++++++++ > > drivers/iommu/{ => virtio}/virtio-iommu.c | 4 + > > drivers/pci/pci-driver.c | 5 + > > MAINTAINERS | 3 +- > > 11 files changed, 597 insertions(+), 4 deletions(-) > > create mode 100644 drivers/iommu/virtio/Makefile > > create mode 100644 drivers/iommu/virtio/topology-helpers.h > > create mode 100644 include/linux/virt_iommu.h > > create mode 100644 drivers/iommu/virtio/topology-helpers.c > > create mode 100644 drivers/iommu/virtio/topology.c > > rename drivers/iommu/{ => virtio}/virtio-iommu.c (99%) > >
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: 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. 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 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
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 >
On Thu, Sep 24, 2020 at 12:29:53PM +0200, Jean-Philippe Brucker wrote: > It's not possible to use exactly the same code for parsing. The access methods can be separate and don't affect the parsing logic. > 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. Will it hurt the non-ACPI version to have the not-needed pointers anyway to keep the parsers the same? 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. > > > 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 But 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.
On Thu, Sep 24, 2020 at 08:41:21AM -0400, Michael S. Tsirkin wrote: > But 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. Or Linux decides to support only one of the formats, which would then be ACPI. Regards, Joerg
On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > Add a topology description to the virtio-iommu driver and enable x86 > platforms. > > Since [v2] we have made some progress on adding ACPI support for > virtio-iommu, which is the preferred boot method on x86. It will be a > new vendor-agnostic table describing para-virtual topologies in a > minimal format. However some platforms don't use either ACPI or DT for > booting (for example microvm), and will need the alternative topology > description method proposed here. In addition, since the process to get > a new ACPI table will take a long time, this provides a boot method even > to ACPI-based platforms, if only temporarily for testing and > development. > > v3: > * Add patch 1 that moves virtio-iommu to a subfolder. > * Split the rest: > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > support. > * Patch 4 adds definitions. > * Patch 5 adds parser in topology.c. > * Address other comments. > > Linux and QEMU patches available at: > https://jpbrucker.net/git/linux virtio-iommu/devel > https://jpbrucker.net/git/qemu virtio-iommu/devel I'm parking this work again, until we make progress on the ACPI table, or until a platform without ACPI and DT needs it. Until then, I've pushed v4 to my virtio-iommu/topo branch and will keep it rebased on master. Thanks, Jean
On Thu, Sep 24, 2020 at 02:50:46PM +0200, Joerg Roedel wrote: > On Thu, Sep 24, 2020 at 08:41:21AM -0400, Michael S. Tsirkin wrote: > > But 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. > > Or Linux decides to support only one of the formats, which would then be > ACPI. > > Regards, > > Joerg It's really up to hypervisors not guests, linux as a guest can for sure refuse to work somewhere, but that's normally not very attractive.
On Fri, Sep 25, 2020 at 10:48:06AM +0200, Jean-Philippe Brucker wrote: > On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > > Add a topology description to the virtio-iommu driver and enable x86 > > platforms. > > > > Since [v2] we have made some progress on adding ACPI support for > > virtio-iommu, which is the preferred boot method on x86. It will be a > > new vendor-agnostic table describing para-virtual topologies in a > > minimal format. However some platforms don't use either ACPI or DT for > > booting (for example microvm), and will need the alternative topology > > description method proposed here. In addition, since the process to get > > a new ACPI table will take a long time, this provides a boot method even > > to ACPI-based platforms, if only temporarily for testing and > > development. > > > > v3: > > * Add patch 1 that moves virtio-iommu to a subfolder. > > * Split the rest: > > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > > support. > > * Patch 4 adds definitions. > > * Patch 5 adds parser in topology.c. > > * Address other comments. > > > > Linux and QEMU patches available at: > > https://jpbrucker.net/git/linux virtio-iommu/devel > > https://jpbrucker.net/git/qemu virtio-iommu/devel > > I'm parking this work again, until we make progress on the ACPI table, or > until a platform without ACPI and DT needs it. Until then, I've pushed v4 > to my virtio-iommu/topo branch and will keep it rebased on master. > > Thanks, > Jean I think you guys need to work on virtio spec too, not too much left to do there ...
On Fri, Sep 25, 2020 at 06:22:57AM -0400, Michael S. Tsirkin wrote: > On Fri, Sep 25, 2020 at 10:48:06AM +0200, Jean-Philippe Brucker wrote: > > On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > > > Add a topology description to the virtio-iommu driver and enable x86 > > > platforms. > > > > > > Since [v2] we have made some progress on adding ACPI support for > > > virtio-iommu, which is the preferred boot method on x86. It will be a > > > new vendor-agnostic table describing para-virtual topologies in a > > > minimal format. However some platforms don't use either ACPI or DT for > > > booting (for example microvm), and will need the alternative topology > > > description method proposed here. In addition, since the process to get > > > a new ACPI table will take a long time, this provides a boot method even > > > to ACPI-based platforms, if only temporarily for testing and > > > development. > > > > > > v3: > > > * Add patch 1 that moves virtio-iommu to a subfolder. > > > * Split the rest: > > > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > > > support. > > > * Patch 4 adds definitions. > > > * Patch 5 adds parser in topology.c. > > > * Address other comments. > > > > > > Linux and QEMU patches available at: > > > https://jpbrucker.net/git/linux virtio-iommu/devel > > > https://jpbrucker.net/git/qemu virtio-iommu/devel > > > > I'm parking this work again, until we make progress on the ACPI table, or > > until a platform without ACPI and DT needs it. Until then, I've pushed v4 > > to my virtio-iommu/topo branch and will keep it rebased on master. > > > > Thanks, > > Jean > > I think you guys need to work on virtio spec too, not too much left to > do there ... I know it's ready and I'd really like to move on with this, but I'd rather not commit it to the spec until we know it's going to be used at all. As Gerd pointed out the one example we had, microvm, now supports ACPI. Since we've kicked off the ACPI work anyway it isn't clear that the built-in topology will be useful. Thanks, Jean
On Fri, Sep 25, 2020 at 01:26:29PM +0200, Jean-Philippe Brucker wrote: > On Fri, Sep 25, 2020 at 06:22:57AM -0400, Michael S. Tsirkin wrote: > > On Fri, Sep 25, 2020 at 10:48:06AM +0200, Jean-Philippe Brucker wrote: > > > On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote: > > > > Add a topology description to the virtio-iommu driver and enable x86 > > > > platforms. > > > > > > > > Since [v2] we have made some progress on adding ACPI support for > > > > virtio-iommu, which is the preferred boot method on x86. It will be a > > > > new vendor-agnostic table describing para-virtual topologies in a > > > > minimal format. However some platforms don't use either ACPI or DT for > > > > booting (for example microvm), and will need the alternative topology > > > > description method proposed here. In addition, since the process to get > > > > a new ACPI table will take a long time, this provides a boot method even > > > > to ACPI-based platforms, if only temporarily for testing and > > > > development. > > > > > > > > v3: > > > > * Add patch 1 that moves virtio-iommu to a subfolder. > > > > * Split the rest: > > > > * Patch 2 adds topology-helper.c, which will be shared with the ACPI > > > > support. > > > > * Patch 4 adds definitions. > > > > * Patch 5 adds parser in topology.c. > > > > * Address other comments. > > > > > > > > Linux and QEMU patches available at: > > > > https://jpbrucker.net/git/linux virtio-iommu/devel > > > > https://jpbrucker.net/git/qemu virtio-iommu/devel > > > > > > I'm parking this work again, until we make progress on the ACPI table, or > > > until a platform without ACPI and DT needs it. Until then, I've pushed v4 > > > to my virtio-iommu/topo branch and will keep it rebased on master. > > > > > > Thanks, > > > Jean > > > > I think you guys need to work on virtio spec too, not too much left to > > do there ... > > I know it's ready and I'd really like to move on with this, but I'd rather > not commit it to the spec until we know it's going to be used at all. As > Gerd pointed out the one example we had, microvm, now supports ACPI. Since > we've kicked off the ACPI work anyway it isn't clear that the built-in > topology will be useful. > > Thanks, > Jean Many power platforms are OF based, thus without ACPI or DT support.
Hi,
> Many power platforms are OF based, thus without ACPI or DT support.
pseries has lots of stuff below /proc/device-tree. Dunno whenever that
is the same kind of device tree we have on arm ...
take care,
Gerd
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.
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 > > >
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 > >> >>> >>> 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 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 > >>> > >> > > >
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 > 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 virtualization@lists.linux-foundation.org and virtio-dev@lists.oasis-open.org). I'm happy to answer any question, and the folks on here are a good set to Cc: eric.auger@redhat.com jean-philippe@linaro.org joro@8bytes.org kevin.tian@intel.com lorenzo.pieralisi@arm.com mst@redhat.com sebastien.boeuf@intel.com Thanks, Jean
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 virtualization@lists.linux-foundation.org and > virtio-dev@lists.oasis-open.org). I'm happy to answer any question, and > the folks on here are a good set to Cc: > > eric.auger@redhat.com > jean-philippe@linaro.org > joro@8bytes.org > kevin.tian@intel.com > lorenzo.pieralisi@arm.com > mst@redhat.com > sebastien.boeuf@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.
Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will need the alternative topology description method proposed here. In addition, since the process to get a new ACPI table will take a long time, this provides a boot method even to ACPI-based platforms, if only temporarily for testing and development. v3: * Add patch 1 that moves virtio-iommu to a subfolder. * Split the rest: * Patch 2 adds topology-helper.c, which will be shared with the ACPI support. * Patch 4 adds definitions. * Patch 5 adds parser in topology.c. * Address other comments. Linux and QEMU patches available at: https://jpbrucker.net/git/linux virtio-iommu/devel https://jpbrucker.net/git/qemu virtio-iommu/devel [spec] https://lists.oasis-open.org/archives/virtio-dev/202008/msg00067.html [v2] https://lore.kernel.org/linux-iommu/20200228172537.377327-1-jean-philippe@linaro.org/ [v1] https://lore.kernel.org/linux-iommu/20200214160413.1475396-1-jean-philippe@linaro.org/ [rfc] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/ Jean-Philippe Brucker (6): iommu/virtio: Move to drivers/iommu/virtio/ iommu/virtio: Add topology helpers PCI: Add DMA configuration for virtual platforms iommu/virtio: Add topology definitions iommu/virtio: Support topology description in config space iommu/virtio: Enable x86 support drivers/iommu/Kconfig | 18 +- drivers/iommu/Makefile | 3 +- drivers/iommu/virtio/Makefile | 4 + drivers/iommu/virtio/topology-helpers.h | 50 +++++ include/linux/virt_iommu.h | 15 ++ include/uapi/linux/virtio_iommu.h | 44 ++++ drivers/iommu/virtio/topology-helpers.c | 196 ++++++++++++++++ drivers/iommu/virtio/topology.c | 259 ++++++++++++++++++++++ drivers/iommu/{ => virtio}/virtio-iommu.c | 4 + drivers/pci/pci-driver.c | 5 + MAINTAINERS | 3 +- 11 files changed, 597 insertions(+), 4 deletions(-) create mode 100644 drivers/iommu/virtio/Makefile create mode 100644 drivers/iommu/virtio/topology-helpers.h create mode 100644 include/linux/virt_iommu.h create mode 100644 drivers/iommu/virtio/topology-helpers.c create mode 100644 drivers/iommu/virtio/topology.c rename drivers/iommu/{ => virtio}/virtio-iommu.c (99%)