VFIO driver: Non-privileged user level PCI drivers
in [Kernel]
|
From: Chris Wright on 2 Jun 2010 13:00 * Avi Kivity (avi(a)redhat.com) wrote: > The interface would only work for clients which support it: kvm, > vhost, and iommu/devices with restartable dma. BTW, there is no such thing as restartable dma. There is a provision in new specs (read: no real hardware) that allows a device to request pages before using them. So it's akin to demand paging, but the demand is an explicit request rather than a page fault. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chris Wright on 2 Jun 2010 13:50 * Joerg Roedel (joro(a)8bytes.org) wrote: > On Wed, Jun 02, 2010 at 02:21:00PM +0300, Michael S. Tsirkin wrote: > > On Wed, Jun 02, 2010 at 01:12:25PM +0200, Joerg Roedel wrote: > > > > Even if it is bound to a domain the userspace driver could program the > > > device to do dma to unmapped regions causing io-page-faults. The kernel > > > can't do anything about it. > > > > It can always corrupt its own memory directly as well :) > > But that is not a reason not to detect errors if we can, > > and not to make APIs hard to misuse. > > Changing the domain of a device while dma can happen is the same type of > bug as unmapping potential dma target addresses. We can't catch this > kind of misuse. > > > > > With 10 devices you have 10 extra ioctls. > > > > > > And this works implicitly with your proposal? > > > > Yes. so you do: > > iommu = open > > ioctl(dev1, BIND, iommu) > > ioctl(dev2, BIND, iommu) > > ioctl(dev3, BIND, iommu) > > ioctl(dev4, BIND, iommu) > > > > No need to add a SHARE ioctl. > > In my proposal this looks like: > > > dev1 = open(); > ioctl(dev2, SHARE, dev1); > ioctl(dev3, SHARE, dev1); > ioctl(dev4, SHARE, dev1); > > So we actually save an ioctl. This is not any hot path, so saving an ioctl shouldn't be a consideration. Only important consideration is a good API. I may have lost context here, but the SHARE API is limited to the vfio fd. The BIND API expects a new iommu object. Are there other uses for this object? Tom's current vfio driver exposes a dma mapping interface, would the iommu object expose one as well? Current interface is device specific DMA interface for host device drivers typically mapping in-flight dma buffers, and IOMMU specific interface for assigned devices typically mapping entire virtual address space. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tom Lyon on 2 Jun 2010 14:20 On Wednesday 02 June 2010 10:46:15 am Chris Wright wrote: > * Joerg Roedel (joro(a)8bytes.org) wrote: > > On Wed, Jun 02, 2010 at 02:21:00PM +0300, Michael S. Tsirkin wrote: > > > On Wed, Jun 02, 2010 at 01:12:25PM +0200, Joerg Roedel wrote: > > > > > > Even if it is bound to a domain the userspace driver could program the > > > > device to do dma to unmapped regions causing io-page-faults. The kernel > > > > can't do anything about it. > > > > > > It can always corrupt its own memory directly as well :) > > > But that is not a reason not to detect errors if we can, > > > and not to make APIs hard to misuse. > > > > Changing the domain of a device while dma can happen is the same type of > > bug as unmapping potential dma target addresses. We can't catch this > > kind of misuse. > > > > > > > With 10 devices you have 10 extra ioctls. > > > > > > > > And this works implicitly with your proposal? > > > > > > Yes. so you do: > > > iommu = open > > > ioctl(dev1, BIND, iommu) > > > ioctl(dev2, BIND, iommu) > > > ioctl(dev3, BIND, iommu) > > > ioctl(dev4, BIND, iommu) > > > > > > No need to add a SHARE ioctl. > > > > In my proposal this looks like: > > > > > > dev1 = open(); > > ioctl(dev2, SHARE, dev1); > > ioctl(dev3, SHARE, dev1); > > ioctl(dev4, SHARE, dev1); > > > > So we actually save an ioctl. > > This is not any hot path, so saving an ioctl shouldn't be a consideration. > Only important consideration is a good API. I may have lost context here, > but the SHARE API is limited to the vfio fd. The BIND API expects a new > iommu object. Are there other uses for this object? Tom's current vfio > driver exposes a dma mapping interface, would the iommu object expose > one as well? Current interface is device specific DMA interface for > host device drivers typically mapping in-flight dma buffers, and IOMMU > specific interface for assigned devices typically mapping entire virtual > address space. Actually, it a domain object - which may be usable among iommus (Joerg?). However, you can't really do the dma mapping with just the domain because every device supports a different size address space as a master, i.e., the dma_mask. And I don't know how kvm would deal with devices with varying dma mask support, or why they'd be in the same domain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 2 Jun 2010 15:50 On Wed, Jun 02, 2010 at 11:09:17AM -0700, Tom Lyon wrote: > On Wednesday 02 June 2010 10:46:15 am Chris Wright wrote: > > This is not any hot path, so saving an ioctl shouldn't be a consideration. > > Only important consideration is a good API. I may have lost context here, > > but the SHARE API is limited to the vfio fd. The BIND API expects a new > > iommu object. Are there other uses for this object? Tom's current vfio > > driver exposes a dma mapping interface, would the iommu object expose > > one as well? Current interface is device specific DMA interface for > > host device drivers typically mapping in-flight dma buffers, and IOMMU > > specific interface for assigned devices typically mapping entire virtual > > address space. > > Actually, it a domain object - which may be usable among iommus (Joerg?). Yes, this 'iommu' thing is would be a domain object. But sharing among iommus is not necessary because the fact that there are multiple iommus in the system is hidden by the iommu drivers. This fact is not even exposed by the iommu-api. This makes protection domains system global. > However, you can't really do the dma mapping with just the domain because > every device supports a different size address space as a master, i.e., > the dma_mask. The dma_mask has to be handled by the device driver. With the iommu-mapping interface the driver can specify the target io-address and has to consider the dma_mask for that too. > And I don't know how kvm would deal with devices with varying dma mask support, > or why they'd be in the same domain. KVM does not care about these masks. This is the business of the guest device drivers. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 3 Jun 2010 02:30
On 06/02/2010 08:46 PM, Chris Wright wrote: > The BIND API expects a new > iommu object. Are there other uses for this object? Both kvm and vhost use similar memory maps, so they could use the new object (without invoking the iommu unless they want dma). > Tom's current vfio > driver exposes a dma mapping interface, would the iommu object expose > one as well? Current interface is device specific DMA interface for > host device drivers typically mapping in-flight dma buffers, and IOMMU > specific interface for assigned devices typically mapping entire virtual > address space. > A per-request mapping sounds like a device API since it would only affect that device (whereas the address space API affects multiple devices). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |