> From: Neo Jia > Sent: Friday, March 11, 2016 2:11 PM > > > Hi Jike, > > > > > > For vGPU, what we have is just a virtual device and a fake IOMMU group, therefore > > > the actual interaction with the real GPU should be managed by the GPU vendor driver. > > > > > > > Hi, Neo, > > > > Seems we have a different thought on this. Regardless of whether it's a virtual/physical > > device, imo, VFIO should manage IOMMU configuration. The only difference is: > > > > - for physical device, VFIO directly invokes IOMMU API to set IOMMU entry (GPA->HPA); > > - for virtual device, VFIO invokes kernel DMA APIs which indirectly lead to IOMMU entry > > set if CONFIG_IOMMU is enabled in kernel (GPA->IOVA); > > How does it make any sense for us to do a dma_map_page for a physical device that we > don't > have any direct interaction with? > That is also a valid point. It really depends on how we look at this issue. >From VFIO p.o.v, it needs to enforce DMA isolation for managed devices. In that manner it doesn't matter whether it's a physical or virtual one. However if looking at specific linux DMA interface, you are right that it is built around the physical device instance, which is not managed by VFIO in this case. On the other hand, your proposal leaves DMA mapping to vendor specific driver which actually manages physical device. However this way VFIO relies on other agent to enforce DMA isolation of vGPUs. Might not be a real problem (more a conceptual one)... So let me do more thinking here (half-way convinced by you) :-) Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
