similar to: [RFC 00/13] virtio-iommu on non-devicetree platforms

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

On Fri, Nov 22, 2019 at 11:49:47AM +0100, Jean-Philippe Brucker wrote: > I'm seeking feedback on multi-platform support for virtio-iommu. At the > moment only devicetree (DT) is supported and we don't have a pleasant > solution for other platforms. Once we figure out the topology > description, x86 support is trivial. > > Since the IOMMU manages memory accesses from

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

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 +++++++++++++++++++++++++++++++++++--------- 1 file

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 +

Hi Eric, On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > Michael has pushed this solution (putting the "configuration in the PCI > config space"), I think for those main reasons: > - ACPI may not be supported on some archs/hyps But on those there is device-tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The

Hi Eric, On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > Michael has pushed this solution (putting the "configuration in the PCI > config space"), I think for those main reasons: > - ACPI may not be supported on some archs/hyps But on those there is device-tree, right? > - the virtio-iommu is a PCIe device so binding should not need ACPI > description The

On Tue, Mar 03, 2020 at 02:01:56PM +0100, Joerg Roedel wrote: > Hi Eric, > > On Tue, Mar 03, 2020 at 11:19:20AM +0100, Auger Eric wrote: > > Michael has pushed this solution (putting the "configuration in the PCI > > config space"), I think for those main reasons: > > - ACPI may not be supported on some archs/hyps > > But on those there is device-tree,

Hi Joerg, On 3/2/20 5:16 PM, Joerg Roedel wrote: > 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

Unlike other virtio devices, the virtio-iommu doesn't work independently, it is linked to other virtual or assigned devices. So before jumping into device operations, we need to define a way for the guest to discover the virtual IOMMU and the devices it translates. The host must describe the relation between IOMMU and devices to the guest using either device-tree or ACPI. The virtual IOMMU

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 e45ced27f4c3..99c1d747e9d8 100644 --- a/include/acpi/actbl2.h +++

On Tue, Nov 27, 2018 at 06:09:25PM +0100, Auger Eric wrote: > Hi Michael, > > On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: > >> Implement the virtio-iommu driver, following specification v0.9 [1]. > >> > >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by

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, 4 insertions(+),

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 + >

On 18/04/17 10:51, Tian, Kevin wrote: >> From: Jean-Philippe Brucker >> Sent: Saturday, April 8, 2017 3:18 AM >> >> Unlike other virtio devices, the virtio-iommu doesn't work independently, >> it is linked to other virtual or assigned devices. So before jumping into >> device operations, we need to define a way for the guest to discover the >> virtual

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, April 19, 2017 2:41 AM > > On 18/04/17 10:51, Tian, Kevin wrote: > >> From: Jean-Philippe Brucker > >> Sent: Saturday, April 8, 2017 3:18 AM > >> > >> Unlike other virtio devices, the virtio-iommu doesn't work independently, > >> it is linked to

Hi Michael, On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: >> Implement the virtio-iommu driver, following specification v0.9 [1]. >> >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by >> from Eric and Rob. Thanks! >> >> I changed the specification to fix one

Hi Michael, On 11/27/18 5:53 PM, Michael S. Tsirkin wrote: > On Thu, Nov 22, 2018 at 07:37:54PM +0000, Jean-Philippe Brucker wrote: >> Implement the virtio-iommu driver, following specification v0.9 [1]. >> >> Since v4 [2] I fixed the issues reported by Eric, and added Reviewed-by >> from Eric and Rob. Thanks! >> >> I changed the specification to fix one