similar to: [RFC] virtio-iommu version 0.5

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

Please find version 0.6 of the virtio-iommu specification at the following locations. Document: http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.pdf http://jpbrucker.net/virtio-iommu/spec/virtio-iommu.html Sources: git://linux-arm.org/virtio-iommu.git viommu/v0.6 I didn't receive any comment for v0.5 [1], so this update is fairly light: * Changed range definition in map and

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version

Hi Jean, Thanks for your reply. On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > Hi Linu, > > On 24/10/17 07:27, Linu Cherian wrote: > > Hi Jean, > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > >> This is version 0.5 of the virtio-iommu specification, the paravirtualized > >> IOMMU. This version

Hi Jean, On Tue Oct 24, 2017 at 10:28:59PM +0530, Linu Cherian wrote: > Hi Jean, > Thanks for your reply. > > On Tue Oct 24, 2017 at 09:37:12AM +0100, Jean-Philippe Brucker wrote: > > Hi Linu, > > > > On 24/10/17 07:27, Linu Cherian wrote: > > > Hi Jean, > > > > > > On Mon Oct 23, 2017 at 10:32:41AM +0100, 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 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

Hi Jean, On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > 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 >

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

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 got merged into > the standard. For example I believe that code for crypto, input and GPU >

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 got merged into > the standard. For example I believe that code for crypto, input and GPU >