search for: viot

Add support for a new ACPI table that embeds other tables describing a platform's IOMMU topology. Currently the only supported base table is IORT. The VIOT contains an IORT with additional node types, that describe a virtio-iommu. Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org> --- drivers/acpi/Kconfig | 4 ++++ drivers/acpi/Makefile | 1 + drivers/acpi/bus.c | 2 ++ drivers/acpi/tables.c | 2 +- driv...

...l with CONFIG_X86. > > However, there are concerns about other OS vendors feeling obligated > to implement this new node, so Arm proposed introducing another ACPI > table, that can wrap any of DMAR, IVRS and IORT to extend it with > new virtual nodes. A draft of this VIOT table specification is > available at http://jpbrucker.net/virtio-iommu/viot/viot-v5.pdf > > I'm afraid this could increase fragmentation as guests would need to > implement or modify their support for all of DMAR, IVRS and IORT. If > we end up doing VIOT, I sugg...

This is temporary, until the VIOT table is published and these definitions added to ACPICA. Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org> --- include/acpi/actbl2.h | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index e45...

...T driver, so it works well with CONFIG_X86. However, there are concerns about other OS vendors feeling obligated to implement this new node, so Arm proposed introducing another ACPI table, that can wrap any of DMAR, IVRS and IORT to extend it with new virtual nodes. A draft of this VIOT table specification is available at http://jpbrucker.net/virtio-iommu/viot/viot-v5.pdf I'm afraid this could increase fragmentation as guests would need to implement or modify their support for all of DMAR, IVRS and IORT. If we end up doing VIOT, I suggest limiting it to IORT....

...T driver, so it works well with CONFIG_X86. However, there are concerns about other OS vendors feeling obligated to implement this new node, so Arm proposed introducing another ACPI table, that can wrap any of DMAR, IVRS and IORT to extend it with new virtual nodes. A draft of this VIOT table specification is available at http://jpbrucker.net/virtio-iommu/viot/viot-v5.pdf I'm afraid this could increase fragmentation as guests would need to implement or modify their support for all of DMAR, IVRS and IORT. If we end up doing VIOT, I suggest limiting it to IORT....

...atic LIST_HEAD(iort_fwnode_list); static DEFINE_SPINLOCK(iort_fwnode_lock); @@ -44,7 +51,8 @@ static bool iort_type_matches(u8 type, enum iort_node_category category) case IORT_IOMMU_TYPE: return type == ACPI_IORT_NODE_SMMU || type == ACPI_IORT_NODE_SMMU_V3 || - type == ACPI_VIOT_IORT_NODE_VIRTIO_MMIO_IOMMU; + type == ACPI_VIOT_IORT_NODE_VIRTIO_MMIO_IOMMU || + type == ACPI_VIOT_IORT_NODE_VIRTIO_PCI_IOMMU; case IORT_MSI_TYPE: return type == ACPI_IORT_NODE_ITS_GROUP; default: @@ -59,12 +67,14 @@ static bool iort_type_matches(u8 type, enum iort_node_cate...

...y point of view IORT is easier to > > > > extend, since we just need to introduce a new node type. There > > > > are no dependencies to Arm in the Linux IORT driver, so it works > > > > well with CONFIG_X86. > > > From my limited understanding, IORT and VIOT is to solve device > > > topology enumeration only? I am not sure how it can be expanded to > > > cover information beyond device topology. e.g. DMAR has NUMA > > > information and root port ATS, I guess they are not used today in > > > the guest but might be add...

...AMD and > > IORT for Arm). From my point of view IORT is easier to extend, since > > we just need to introduce a new node type. There are no dependencies > > to Arm in the Linux IORT driver, so it works well with CONFIG_X86. > > > From my limited understanding, IORT and VIOT is to solve device topology > enumeration only? I am not sure how it can be expanded to cover > information beyond device topology. e.g. DMAR has NUMA information and > root port ATS, I guess they are not used today in the guest but might > be additions in the future. The PCI root-comp...

On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote: > This solution isn't elegant nor foolproof, but is the best we can do at > the moment and works with existing virtio-iommu implementations. It also > enables an IOMMU for lightweight hypervisors that do not rely on > firmware methods for booting. I appreciate the enablement on x86, but putting the

On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote: > This solution isn't elegant nor foolproof, but is the best we can do at > the moment and works with existing virtio-iommu implementations. It also > enables an IOMMU for lightweight hypervisors that do not rely on > firmware methods for booting. I appreciate the enablement on x86, but putting the

...tion with IORT might be the best, but if it is not possible ther can be a new table-type for Virtio-iommu. That would still follow platform best practices. > x86 ACPI integration was suggested with IORT. But it seems ARM is > reluctant to extend IORT to support para-virtualized IOMMU. So the VIOT > was proposed as a different atternative in "[RFC 00/13] virtio-iommu on > non-devicetree platforms" > (https://patchwork.kernel.org/cover/11257727/). Proposing a table that > may be used by different vendors seems to be a challenging issue here. Yeah, if I am reading that r...

...tion with IORT might be the best, but if it is not possible ther can be a new table-type for Virtio-iommu. That would still follow platform best practices. > x86 ACPI integration was suggested with IORT. But it seems ARM is > reluctant to extend IORT to support para-virtualized IOMMU. So the VIOT > was proposed as a different atternative in "[RFC 00/13] virtio-iommu on > non-devicetree platforms" > (https://patchwork.kernel.org/cover/11257727/). Proposing a table that > may be used by different vendors seems to be a challenging issue here. Yeah, if I am reading that r...

.../drivers/acpi/Makefile index eaa09bf52f1760..4e77ae37b80726 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -127,7 +127,7 @@ obj-y += pmic/ video-objs += acpi_video.o video_detect.o obj-y += dptf/ -obj-$(CONFIG_ARM64) += arm64/ +obj-y += arm64/ obj-$(CONFIG_ACPI_VIOT) += viot.o diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig index b3ed6212244c1e..537d49d8ace69e 100644 --- a/drivers/acpi/arm64/Kconfig +++ b/drivers/acpi/arm64/Kconfig @@ -11,6 +11,7 @@ config ACPI_GTDT config ACPI_AGDI bool "Arm Generic Diagnostic Dump and Reset...

...s a PCIe device so binding should not need ACPI description Another issue with ACPI integration is we have different flavours of tables that exist: IORT, DMAR, IVRS x86 ACPI integration was suggested with IORT. But it seems ARM is reluctant to extend IORT to support para-virtualized IOMMU. So the VIOT was proposed as a different atternative in "[RFC 00/13] virtio-iommu on non-devicetree platforms" (https://patchwork.kernel.org/cover/11257727/). Proposing a table that may be used by different vendors seems to be a challenging issue here. So even if the above solution does not look perf...

...he best, but if it is not possible > ther can be a new table-type for Virtio-iommu. That would still follow > platform best practices. > > > x86 ACPI integration was suggested with IORT. But it seems ARM is > > reluctant to extend IORT to support para-virtualized IOMMU. So the VIOT > > was proposed as a different atternative in "[RFC 00/13] virtio-iommu on > > non-devicetree platforms" > > (https://patchwork.kernel.org/cover/11257727/). Proposing a table that > > may be used by different vendors seems to be a challenging issue here. > &gt...

...0726 100644 > --- a/drivers/acpi/Makefile > +++ b/drivers/acpi/Makefile > @@ -127,7 +127,7 @@ obj-y += pmic/ > video-objs += acpi_video.o video_detect.o > obj-y += dptf/ > > -obj-$(CONFIG_ARM64) += arm64/ > +obj-y += arm64/ > > obj-$(CONFIG_ACPI_VIOT) += viot.o > > diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig > index b3ed6212244c1e..537d49d8ace69e 100644 > --- a/drivers/acpi/arm64/Kconfig > +++ b/drivers/acpi/arm64/Kconfig > @@ -11,6 +11,7 @@ config ACPI_GTDT > > config ACPI_AGDI >...

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

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