qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support fo


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU
Date: Fri, 11 Mar 2016 08:06:03 +0000

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]