search for: viommu_event

...gt; index 79e0add94e05..fe0d449bf489 100644 > --- a/drivers/iommu/virtio-iommu.c > +++ b/drivers/iommu/virtio-iommu.c > @@ -30,6 +30,12 @@ > #define MSI_IOVA_BASE 0x8000000 > #define MSI_IOVA_LENGTH 0x100000 > > +enum viommu_vq_idx { > + VIOMMU_REQUEST_VQ = 0, > + VIOMMU_EVENT_VQ = 1, > + VIOMMU_NUM_VQS = 2, > +}; > + > struct viommu_dev { > struct iommu_device iommu; > struct device *dev; > @@ -37,7 +43,7 @@ struct viommu_dev { > > struct ida domain_ids; > > - struct virtqueue *vq; > + struct virtqueue *vqs[VIOMMU_...

...mu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index 3ac4b38eaf19..6b96f1b36d5a 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -30,6 +30,12 @@ #define MSI_IOVA_BASE 0x8000000 #define MSI_IOVA_LENGTH 0x100000 +enum viommu_vq_idx { + VIOMMU_REQUEST_VQ = 0, + VIOMMU_EVENT_VQ = 1, + VIOMMU_NUM_VQS = 2, +}; + struct viommu_dev { struct iommu_device iommu; struct device *dev; @@ -37,9 +43,10 @@ struct viommu_dev { struct ida domain_ids; - struct virtqueue *vq; + struct virtqueue *vqs[VIOMMU_NUM_VQS]; /* Serialize anything touching the request queu...

...mu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index 79e0add94e05..fe0d449bf489 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -30,6 +30,12 @@ #define MSI_IOVA_BASE 0x8000000 #define MSI_IOVA_LENGTH 0x100000 +enum viommu_vq_idx { + VIOMMU_REQUEST_VQ = 0, + VIOMMU_EVENT_VQ = 1, + VIOMMU_NUM_VQS = 2, +}; + struct viommu_dev { struct iommu_device iommu; struct device *dev; @@ -37,7 +43,7 @@ struct viommu_dev { struct ida domain_ids; - struct virtqueue *vq; + struct virtqueue *vqs[VIOMMU_NUM_VQS]; /* Serialize anything touching the request queue...

...--git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index c547ebd79c43..81c6b72e9c43 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -29,7 +29,8 @@ #define MSI_IOVA_LENGTH 0x100000 #define VIOMMU_REQUEST_VQ 0 -#define VIOMMU_NR_VQS 1 +#define VIOMMU_EVENT_VQ 1 +#define VIOMMU_NR_VQS 2 struct viommu_dev { struct iommu_device iommu; @@ -41,6 +42,7 @@ struct viommu_dev { struct virtqueue *vqs[VIOMMU_NR_VQS]; spinlock_t request_lock; struct list_head requests; + void *evts; /* Device configuration */ struct iommu_domain_geom...

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

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.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 version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

Implement the virtio-iommu driver following version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

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

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

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