On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> uio_pci_generic has previously been discussed on the KVM list, but this patch
> has nothing to do with KVM, so it is also going to LKML.
But since you send it to the KVM list it should be suitable for KVM too,
no?
> The point of this patch is to beef up the uio_pci_generic driver so that a
> non-privileged user process can run a user level driver for most PCIe
> devices. This can only be safe if there is an IOMMU in the system with
> per-device domains. Privileged users (CAP_SYS_RAWIO) are allowed if there is
> no IOMMU.
If you rely on an IOMMU you can use the IOMMU-API instead of the DMA-API
for dma mappings. This change makes this driver suitable for KVM use
too. If the interface is designed clever enough we can even use it for
IOMMU emulation for pass-through devices.
Joerg
On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> On Wed, Mar 31, 2010 at 05:08:38PM -0700, Tom Lyon wrote:
> > uio_pci_generic has previously been discussed on the KVM list, but this
> > patch has nothing to do with KVM, so it is also going to LKML.
>
> But since you send it to the KVM list it should be suitable for KVM too,
> no?
I know not.
>
> > The point of this patch is to beef up the uio_pci_generic driver so that
> > a non-privileged user process can run a user level driver for most PCIe
> > devices. This can only be safe if there is an IOMMU in the system with
> > per-device domains. Privileged users (CAP_SYS_RAWIO) are allowed if
> > there is no IOMMU.
>
> If you rely on an IOMMU you can use the IOMMU-API instead of the DMA-API
> for dma mappings. This change makes this driver suitable for KVM use
> too. If the interface is designed clever enough we can even use it for
> IOMMU emulation for pass-through devices.
The use with privileged processes and no IOMMUs is still quite useful, so I'd
rather stick with the DMA interface.
On Thu, Apr 01, 2010 at 08:40:34AM -0700, Tom Lyon wrote:
> On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> > > The point of this patch is to beef up the uio_pci_generic driver so that
> > > a non-privileged user process can run a user level driver for most PCIe
> > > devices. This can only be safe if there is an IOMMU in the system with
> > > per-device domains. Privileged users (CAP_SYS_RAWIO) are allowed if
> > > there is no IOMMU.
> >
> > If you rely on an IOMMU you can use the IOMMU-API instead of the DMA-API
> > for dma mappings. This change makes this driver suitable for KVM use
> > too. If the interface is designed clever enough we can even use it for
> > IOMMU emulation for pass-through devices.
> The use with privileged processes and no IOMMUs is still quite useful, so I'd
> rather stick with the DMA interface.
For the KVM use-case we need to be able to specify the io virtual
address for a given process virtual address. This is not possible with
the dma-api interface. So if we want to have uio-dma without an hardware
iommu we need two distinct interfaces for userspace to cover all
use-cases. I don't think its worth it to have two interfaces.
Joerg
On Thursday 01 April 2010 09:07:47 am Joerg Roedel wrote:
> On Thu, Apr 01, 2010 at 08:40:34AM -0700, Tom Lyon wrote:
> > On Thursday 01 April 2010 05:52:18 am Joerg Roedel wrote:
> > > > The point of this patch is to beef up the uio_pci_generic driver so
> > > > that a non-privileged user process can run a user level driver for
> > > > most PCIe devices. This can only be safe if there is an IOMMU in the
> > > > system with per-device domains. Privileged users (CAP_SYS_RAWIO) are
> > > > allowed if there is no IOMMU.
> > >
> > > If you rely on an IOMMU you can use the IOMMU-API instead of the
> > > DMA-API for dma mappings. This change makes this driver suitable for
> > > KVM use too. If the interface is designed clever enough we can even use
> > > it for IOMMU emulation for pass-through devices.
> >
> > The use with privileged processes and no IOMMUs is still quite useful, so
> > I'd rather stick with the DMA interface.
>
> For the KVM use-case we need to be able to specify the io virtual
> address for a given process virtual address. This is not possible with
> the dma-api interface. So if we want to have uio-dma without an hardware
> iommu we need two distinct interfaces for userspace to cover all
> use-cases. I don't think its worth it to have two interfaces.
>
> Joerg
I started to add that capability but then realized that the IOMMU API also
doesn't allow it. The map function allows a range of physically contiguous
pages, not virtual.
My preferred approach would be to add a DMA_ATTR that would request allocation
of DMA at a specific device/iommu address.
On Thu, Apr 01, 2010 at 12:18:27PM -0700, Tom Lyon wrote:
> On Thursday 01 April 2010 09:07:47 am Joerg Roedel wrote:
> > For the KVM use-case we need to be able to specify the io virtual
> > address for a given process virtual address. This is not possible with
> > the dma-api interface. So if we want to have uio-dma without an hardware
> > iommu we need two distinct interfaces for userspace to cover all
> > use-cases. I don't think its worth it to have two interfaces.
>
> I started to add that capability but then realized that the IOMMU API also
> doesn't allow it. The map function allows a range of physically contiguous
> pages, not virtual.
The IOMMU-API allows that. You have to convert the user-virtual
addresses into physical addresses first. The current KVM code
already does this and uses the IOMMU-API later. You can have a look at
the gfn_to_pfn() function for a way to implement this.
> My preferred approach would be to add a DMA_ATTR that would request
> allocation of DMA at a specific device/iommu address.
No, that would be feature duplication between both APIs. Not to mention
the implementation hell this additional dma-api feature would cause for
the iommu driver developers.
Joerg