search for: vsmmu

On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: > On 23/11/2018 21:56, Michael S. Tsirkin wrote: > >> +config VIRTIO_IOMMU > >> + bool "Virtio IOMMU driver" > >> + depends on VIRTIO=y > >> + select IOMMU_API > >> + select INTERVAL_TREE > >> + select ARM_DMA_USE_IOMMU if ARM > >> + help > >>

...;s reasonably portable. > > If you want to go that way down the road, you should avoid > > virtio iommu, instead emulate and share code with the ARM SMMU (probably > > with a different vendor id so you can implement the > > report on map for devices without PRI). > > vSMMU has to stay in userspace though. The main reason we're proposing > virtio-iommu is that emulating every possible vIOMMU model in the kernel > would be unmaintainable. With virtio-iommu we can process the fast path > in the host kernel, through vhost-iommu, and do the heavy lifting in &...

...n and fault reporting descriptors are fairly generic. > If you want to go that way down the road, you should avoid > virtio iommu, instead emulate and share code with the ARM SMMU (probably > with a different vendor id so you can implement the > report on map for devices without PRI). vSMMU has to stay in userspace though. The main reason we're proposing virtio-iommu is that emulating every possible vIOMMU model in the kernel would be unmaintainable. With virtio-iommu we can process the fast path in the host kernel, through vhost-iommu, and do the heavy lifting in userspace. As sa...

...f you want to go that way down the road, you should avoid >>>> virtio iommu, instead emulate and share code with the ARM SMMU (probably >>>> with a different vendor id so you can implement the >>>> report on map for devices without PRI). >>> >>> vSMMU has to stay in userspace though. The main reason we're proposing >>> virtio-iommu is that emulating every possible vIOMMU model in the kernel >>> would be unmaintainable. With virtio-iommu we can process the fast path >>> in the host kernel, through vhost-iommu, and d...

...> >>> If you want to go that way down the road, you should avoid >>> virtio iommu, instead emulate and share code with the ARM SMMU (probably >>> with a different vendor id so you can implement the >>> report on map for devices without PRI). >> >> vSMMU has to stay in userspace though. The main reason we're proposing >> virtio-iommu is that emulating every possible vIOMMU model in the kernel >> would be unmaintainable. With virtio-iommu we can process the fast path >> in the host kernel, through vhost-iommu, and do the heavy...

...bling Intel RMRR or AMD IVMD on ARM platforms. I do think ARM platforms could need MEM_T_IDENTITY for requesting the guest to map MSI windows when page-table handover is in use (MSI addresses are translated by the physical SMMU, so a IOVA->GPA mapping must be installed by the guest). But since a vSMMU would need a solution as well, I think I'll try to implement something more generic. > 2.6.8.2.3 Device Requirements: Property RESV_MEM > > --citation start-- > If an endpoint is attached to an address space, the device SHOULD leave > any access targeting one of its VIRTIO_IOM...

...bling Intel RMRR or AMD IVMD on ARM platforms. I do think ARM platforms could need MEM_T_IDENTITY for requesting the guest to map MSI windows when page-table handover is in use (MSI addresses are translated by the physical SMMU, so a IOVA->GPA mapping must be installed by the guest). But since a vSMMU would need a solution as well, I think I'll try to implement something more generic. > 2.6.8.2.3 Device Requirements: Property RESV_MEM > > --citation start-- > If an endpoint is attached to an address space, the device SHOULD leave > any access targeting one of its VIRTIO_IOM...

...lt for SMMU. Luckily > I'm still working on adding PASID code for SMMUv3, so extracting it out of > the driver isn't a big overhead. The good thing about this solution is > that it reuses any specification work done for VFIO (and vice versa) and > any host driver change made for vSMMU/VT-d emulations. > > Thanks, > Jean -- Linu cherian

...lt for SMMU. Luckily > I'm still working on adding PASID code for SMMUv3, so extracting it out of > the driver isn't a big overhead. The good thing about this solution is > that it reuses any specification work done for VFIO (and vice versa) and > any host driver change made for vSMMU/VT-d emulations. > > Thanks, > Jean -- Linu cherian

...> > I'm still working on adding PASID code for SMMUv3, so extracting it out of > > the driver isn't a big overhead. The good thing about this solution is > > that it reuses any specification work done for VFIO (and vice versa) and > > any host driver change made for vSMMU/VT-d emulations. > > > > Thanks, > > Jean > > -- > Linu cherian -- Linu cherian

...ry, which is difficult for SMMU. Luckily I'm still working on adding PASID code for SMMUv3, so extracting it out of the driver isn't a big overhead. The good thing about this solution is that it reuses any specification work done for VFIO (and vice versa) and any host driver change made for vSMMU/VT-d emulations. Thanks, Jean

...; I'm still working on adding PASID code for SMMUv3, so extracting it out of >>> the driver isn't a big overhead. The good thing about this solution is >>> that it reuses any specification work done for VFIO (and vice versa) and >>> any host driver change made for vSMMU/VT-d emulations. >>> >>> Thanks, >>> Jean >> >> -- >> Linu cherian >

...VMD on ARM platforms. I do think ARM platforms could need > MEM_T_IDENTITY > for requesting the guest to map MSI windows when page-table handover is > in > use (MSI addresses are translated by the physical SMMU, so a IOVA->GPA > mapping must be installed by the guest). But since a vSMMU would need a > solution as well, I think I'll try to implement something more generic. curious do you need identity mapping full IOVA->GPA->HPA translation, or just in GPA->HPA stage sufficient for above MSI scenario? > > > 2.6.8.2.3 Device Requirements: Property RESV_M...

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 >

...working on adding PASID code for SMMUv3, so extracting it out of > >>> the driver isn't a big overhead. The good thing about this solution is > >>> that it reuses any specification work done for VFIO (and vice versa) and > >>> any host driver change made for vSMMU/VT-d emulations. > >>> > >>> Thanks, > >>> Jean > >> > >> -- > >> Linu cherian > > -- Linu cherian

...working on adding PASID code for SMMUv3, so extracting it out of > >>> the driver isn't a big overhead. The good thing about this solution is > >>> that it reuses any specification work done for VFIO (and vice versa) and > >>> any host driver change made for vSMMU/VT-d emulations. > >>> > >>> Thanks, > >>> Jean > >> > >> -- > >> Linu cherian > > -- Linu cherian

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

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