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

On Fri, Nov 22, 2019 at 11:50:00AM +0100, Jean-Philippe Brucker wrote: > Some hypervisors don't implement either device-tree or ACPI, but still > need a method to describe the IOMMU topology. Read the virtio-iommu > config early and parse the topology description. Hook into the > dma_setup() callbacks to initialize the IOMMU before probing endpoints. > > If the virtio-iommu

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Some hypervisors don't implement either device-tree or ACPI, but still need a method to describe the IOMMU topology. Read the virtio-iommu config early and parse the topology description. Hook into the dma_setup() callbacks to initialize the IOMMU before probing endpoints. If the virtio-iommu uses the virtio-pci transport, this will only work if the PCI root complex is the first device

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 topology description to the virtio-iommu driver and enable x86 platforms. Since the RFC [1] I've mostly given up on ACPI tables, since the internal discussions seem to have reached a dead end. The built-in topology description presented here isn't ideal, but it is simple to implement and doesn't impose a dependency on ACPI or device-tree, which can be beneficial to lightweight

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

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

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

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

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

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early, because we need to > discover the topology before any DMA configuration takes

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

Implement the virtio-iommu driver, following specification v0.9 [1]. Only minor changes since v5 [2]. I fixed issues reported by Michael and added tags from Eric and Bharat. Thanks! You can find Linux driver and kvmtool device on v0.9 branches [3], module and x86 support on virtio-iommu/devel. Also tested with Eric's QEMU device [4]. [1] Virtio-iommu specification v0.9, sources and pdf

Implement the virtio-iommu driver, following specification v0.9 [1]. Only minor changes since v5 [2]. I fixed issues reported by Michael and added tags from Eric and Bharat. Thanks! You can find Linux driver and kvmtool device on v0.9 branches [3], module and x86 support on virtio-iommu/devel. Also tested with Eric's QEMU device [4]. [1] Virtio-iommu specification v0.9, sources and pdf

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 inconsistency discussed in v4. That the device fills the probe buffer with zeroes is now a "SHOULD" instead of a "MAY", since it's the only way for the driver to know

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 inconsistency discussed in v4. That the device fills the probe buffer with zeroes is now a "SHOULD" instead of a "MAY", since it's the only way for the driver to know