similar to: [PATCH v7 0/7] Add virtio-iommu driver

Hi Thiago, On 21/02/2019 22:18, Thiago Jung Bauermann wrote: > > Hello Jean-Philippe, > > Jean-Philippe Brucker <jean-philippe.brucker at arm.com> writes: >> Makes sense, though I think other virtio devices have been developed a >> little more organically: device and driver code got upstreamed first, >> and then the specification describing their interface

Following specification review a few things were changed in v8 of the virtio-iommu series [1], but have been omitted when merging the base driver. Add them now: * Remove the EXEC flag. * Add feature bit for the MMIO flag. * Change domain_bits to domain_range. * Add NOMEM status flag. [1] https://lore.kernel.org/linux-iommu/20190530170929.19366-1-jean-philippe.brucker at arm.com/ Fixes:

Following specification review a few things were changed in v8 of the virtio-iommu series [1], but have been omitted when merging the base driver. Add them now: * Remove the EXEC flag. * Add feature bit for the MMIO flag. * Change domain_bits to domain_range. * Add NOMEM status flag. [1] https://lore.kernel.org/linux-iommu/20190530170929.19366-1-jean-philippe.brucker at arm.com/ Fixes:

On Fri, Oct 12, 2018 at 03:59:15PM +0100, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

On Fri, Oct 12, 2018 at 03:59:15PM +0100, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

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

This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > ================ > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious do you see such situation where low end of the address space is not usable

> From: Jean-Philippe Brucker > Sent: Saturday, April 8, 2017 3:18 AM > [...] > II. Feature bits > ================ > > VIRTIO_IOMMU_F_INPUT_RANGE (0) > Available range of virtual addresses is described in input_range Usually only the maximum supported address bits are important. Curious do you see such situation where low end of the address space is not usable

Implement the virtio-iommu driver, following specification v0.12 [1]. Since last version [2] we've worked on improving the specification, which resulted in the following changes to the interface: * Remove the EXEC flag. * Add feature bit for the MMIO flag. * Change domain_bits to domain_range. Given that there were small changes to patch 5/7, I removed the review and test tags. Please find

Implement the base virtio-iommu driver, following version 0.7 of the specification [1]. Changes since last version [2]: * Address comments, thanks again for the review. * As suggested, add a DT binding description in patch 1. * Depend on VIRTIO_MMIO=y to fix a build failure? * Switch to v0.7 of the spec, which changes resv_mem parameters and adds an MMIO flag. These are trivial but not backward

Implement the base virtio-iommu driver, following version 0.7 of the specification [1]. Changes since last version [2]: * Address comments, thanks again for the review. * As suggested, add a DT binding description in patch 1. * Depend on VIRTIO_MMIO=y to fix a build failure? * Switch to v0.7 of the spec, which changes resv_mem parameters and adds an MMIO flag. These are trivial but not backward

On Thu, Jun 21, 2018 at 08:06:52PM +0100, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without emulating > page tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

On Thu, Nov 22, 2018 at 07:37:59PM +0000, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

On Thu, Nov 22, 2018 at 07:37:59PM +0000, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio transport without emulating page > tables. This implementation handles ATTACH, DETACH, MAP and UNMAP > requests. > > The bulk of the code transforms calls coming from the IOMMU API into >

Implement the virtio-iommu driver, following specification v0.8 [1]. Changes since v3 [2]: * Rebase onto v4.20-rc2. Patch 3 now touches drivers/of/base.c instead of drivers/pci/of.c, since the map_rid() function has moved. * Removed the request timeout, that depended on DEBUG. * Other small fixes addressing comments on v3. You can find Linux driver and kvmtool device on my virtio-iommu/v0.8.1

Implement the virtio-iommu driver, following specification v0.8 [1]. Changes since v2 [2]: * Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU would like to phase out the MMIO transport. This produces a complex topology where the programming interface of the IOMMU could appear lower than the endpoints that it translates. It's not unheard of (e.g. AMD IOMMU), and the

Implement the virtio-iommu driver, following specification v0.8 [1]. Changes since v2 [2]: * Patches 2-4 allow virtio-iommu to use the PCI transport, since QEMU would like to phase out the MMIO transport. This produces a complex topology where the programming interface of the IOMMU could appear lower than the endpoints that it translates. It's not unheard of (e.g. AMD IOMMU), and the