search for: iort

...:26PM +0100, Lorenzo Pieralisi wrote: > On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote: > > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote: > > > > > I don't think it should be done this way. Is the goal compile testing > > > IORT code ? > > > > Yes > > > > > If so, why are we forcing it through the SMMU (only because > > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ? > > > > Because something needs to select it, and SMMU is one of the places &g...

When virtio-iommu uses the PCI transport, IORT doesn't instantiate the device and doesn't create a fwnode. They will be created later by the PCI subsystem. Store the information needed to identify the IOMMU in iort_fwnode_list. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> --- drivers/acpi/iort.c | 117...

...ndpoints start issuing DMA. > It's a solved problem: firmware or hypervisor describes through DT or > ACPI tables the device dependencies, and probe of endpoints is deferred > until the IOMMU is probed. But: > > (1) ACPI has one table per vendor (DMAR for Intel, IVRS for 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. > > However, there are concerns about other OS vendors feelin...

To describe the virtual topology in relation to a virtio-iommu device, ACPI-based systems use a "paravirtualized IOMMU" IORT node. Add support for it. This is a RFC because the IORT specification doesn't describe the paravirtualized node at the moment, it is only provided as an example in the virtio-iommu spec. What we need to do first is confirm that x86 kernels are able to use the IORT driver with the virtio-iommu...

For a PCI-based IOMMU, IORT isn't in charge of allocating a fwnode. Let the IOMMU driver update the fwnode associated to an IORT node when available. Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org> --- drivers/acpi/iort.c | 38 ++++++++++++++++++++++++++++++++++++++ include/linux/acpi_iort...

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: > The arm-smmu driver can COMPILE_TEST on x86, so expand this to also > enable the IORT code so it can be COMPILE_TEST'd too. > > Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> > --- > drivers/acpi/Kconfig | 2 -- > drivers/acpi/Makefile | 2 +- > drivers/acpi/arm64/Kconfig | 1 + > drivers/acpi/arm64/Makefile | 2 +- > driver...

The arm-smmu driver can COMPILE_TEST on x86, so expand this to also enable the IORT code so it can be COMPILE_TEST'd too. Signed-off-by: Jason Gunthorpe <jgg at nvidia.com> --- drivers/acpi/Kconfig | 2 -- drivers/acpi/Makefile | 2 +- drivers/acpi/arm64/Kconfig | 1 + drivers/acpi/arm64/Makefile | 2 +- drivers/iommu/Kconfig | 1 + 5 files changed,...

...ialize the IOMMU before endpoints start issuing DMA. It's a solved problem: firmware or hypervisor describes through DT or ACPI tables the device dependencies, and probe of endpoints is deferred until the IOMMU is probed. But: (1) ACPI has one table per vendor (DMAR for Intel, IVRS for 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. However, there are concerns about other OS vendors feeling obligated to implem...

...ialize the IOMMU before endpoints start issuing DMA. It's a solved problem: firmware or hypervisor describes through DT or ACPI tables the device dependencies, and probe of endpoints is deferred until the IOMMU is probed. But: (1) ACPI has one table per vendor (DMAR for Intel, IVRS for 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. However, there are concerns about other OS vendors feeling obligated to implem...

The current node filtering won't work when introducing node types greater than 63 (such as the virtio-iommu nodes). Add node_type_matches() to filter nodes by category. Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org> --- drivers/acpi/iort.c | 34 ++++++++++++++++++++++++---------- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/drivers/acpi/iort.c b/drivers/acpi/iort.c index 9c6c91e06f8f..1d43fbc0001f 100644 --- a/drivers/acpi/iort.c +++ b/drivers/acpi/iort.c @@ -18,10 +18,10 @@ #include <linux/platform_device.h&...

.... >> >> You can find Linux driver and kvmtool device on branches >> virtio-iommu/v0.9 [3]. I also lightly tested with Eric's latest QEMU >> device [4]. > > I tried to get this to work on my x86 box but without > success. Any hints? Does this have to do with the IORT table? > I think we really should just reserve our own table ID > and avoid the pain of trying to add things to the IORT spec. > I'm reluctant to merge lots of code that I can't easily test. > Again, if we found a way to push more configuration into > virtio config space the...

.... >> >> You can find Linux driver and kvmtool device on branches >> virtio-iommu/v0.9 [3]. I also lightly tested with Eric's latest QEMU >> device [4]. > > I tried to get this to work on my x86 box but without > success. Any hints? Does this have to do with the IORT table? > I think we really should just reserve our own table ID > and avoid the pain of trying to add things to the IORT spec. > I'm reluctant to merge lots of code that I can't easily test. > Again, if we found a way to push more configuration into > virtio config space the...

...rver which > using smmu-v3 with ACPI booting, but triggered a NULL > pointer dereference and panic at boot: I think that's because patch 01/14 move the fwspec access too early. In err = pci_for_each_dma_alias(to_pci_dev(dev), iort_pci_iommu_init, &info); if (!err && iort_pci_rc_supports_ats(node)) dev->iommu_fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS; the iommu_fwspec is only valid if iort_pci_iommu_init() initialized it successfully, if err == 0. The following might...

...ost must describe the relation between IOMMU and devices to the > >> guest > >> using either device-tree or ACPI. The virtual IOMMU identifies each > > > > Do you plan to support both device tree and ACPI? > > Yes, with ACPI the topology would be described using IORT nodes. I didn't > include an example in my driver because DT is sufficient for a prototype > and is readily available (both in Linux and kvmtool), whereas IORT would > be quite easy to reuse in Linux, but isn't present in kvmtool at the > moment. However, both interfaces have to...

...ost must describe the relation between IOMMU and devices to the > >> guest > >> using either device-tree or ACPI. The virtual IOMMU identifies each > > > > Do you plan to support both device tree and ACPI? > > Yes, with ACPI the topology would be described using IORT nodes. I didn't > include an example in my driver because DT is sufficient for a prototype > and is readily available (both in Linux and kvmtool), whereas IORT would > be quite easy to reuse in Linux, but isn't present in kvmtool at the > moment. However, both interfaces have to...

...nism. Curious how devices in virtio-mmio are enumerated today? Could we use that mechanism to identify vIOMMUs and then invent a purely para-virtualized method to enumerate devices behind each vIOMMU? Asking this is because each vendor has its own enumeration methods. ARM has device tree and ACPI IORT. AMR has ACPI IVRS and device tree (same format as ARM?). Intel has APCI DMAR and sub-tables. Your current proposal looks following ARM definitions which I'm not sure extensible enough to cover features defined only in other vendors' structures. Since the purpose of this series is to go...

...nism. Curious how devices in virtio-mmio are enumerated today? Could we use that mechanism to identify vIOMMUs and then invent a purely para-virtualized method to enumerate devices behind each vIOMMU? Asking this is because each vendor has its own enumeration methods. ARM has device tree and ACPI IORT. AMR has ACPI IVRS and device tree (same format as ARM?). Intel has APCI DMAR and sub-tables. Your current proposal looks following ARM definitions which I'm not sure extensible enough to cover features defined only in other vendors' structures. Since the purpose of this series is to go...

On Fri, Nov 22, 2019 at 04:01:02PM -0800, Jacob Pan (Jun) wrote: > > (1) ACPI has one table per vendor (DMAR for Intel, IVRS for 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...

...tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The other x86 IOMMUs are PCI devices too and they definitly need a ACPI table to be configured. > Another issue with ACPI integration is we have different flavours of > tables that exist: IORT, DMAR, IVRS An integration 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-vi...

...tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The other x86 IOMMUs are PCI devices too and they definitly need a ACPI table to be configured. > Another issue with ACPI integration is we have different flavours of > tables that exist: IORT, DMAR, IVRS An integration 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-vi...