This is somewhat off-topic, but given the various concepts discussed in
this thread I'm beginning to wonder how they will be implemented. The
current implementation hooks the IOMMU API into the DMA mapping API, and
the way this is done is by setting a single IOMMU (or rather a set of
IOMMU operatio
On 06/06/2014 10:21 AM, Eli Billauer wrote:
On 06/06/14 19:01, Greg KH wrote:
Please try to put yourself in my position: I have a driver that I care
> about, which works fine for a few years. It's based upon
dma_map_single(),
> which seems to be the common way to get non-coherent memory, even
On Fri, Jun 6, 2014 at 12:19 AM, Alex Williamson
wrote:
> On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
>> Sharing the same spinlock with the VFIO bus driver is not necessary for
>> the virqfd code, so remove that dependency.
>
> I like the idea of consolidating this code, but I need
On Thu, Jun 5, 2014 at 11:14 PM, Alex Williamson
wrote:
> On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
>> A VFIO userspace driver will start by opening the VFIO device
>> that corresponds to an IOMMU group, and will use the ioctl interface
>> to get the basic device info, such as num
On Thu, Jun 5, 2014 at 10:03 PM, Alex Williamson wrote:
> On Thu, 2014-06-05 at 19:03 +0200, Antonios Motakis wrote:
> > Some IOMMUs accept an IOMMU_NOEXEC protection flag in addition to
> > IOMMU_READ and IOMMU_WRITE. Expose this as an IOMMU capability.
> >
> > Signed-off-by: Antonios Motakis
>
On 06/06/14 19:01, Greg KH wrote:
Please try to put yourself in my position: I have a driver that I care
> about, which works fine for a few years. It's based upon dma_map_single(),
> which seems to be the common way to get non-coherent memory, even for the
> driver's entire lifespan. I realiz
On Fri, Jun 06, 2014 at 02:45:06PM +0300, Eli Billauer wrote:
> Hello Joerg.
>
>
> On 05/06/14 00:25, Joerg Roedel wrote:
> >
> >What you are trying to do should work with dma_alloc_noncoherent(). The
> >API allows partial syncs on this memory, so you should be fine.
> Please try to put yourself
On 06/06/2014 06:55 AM, Peter Hurley wrote:
>
> This won't work either, and should generate a compile or link error
> on CONFIG_X86_32.
>
> The auto-sizing done by __cmpxchg() does not substitute the cmpxchg8b
> instruction for the cmpxchg instruction. __X86_CASE_Q is defined as -1 for
> CONFIG_X
Hello Joerg.
On 05/06/14 00:25, Joerg Roedel wrote:
What you are trying to do should work with dma_alloc_noncoherent(). The
API allows partial syncs on this memory, so you should be fine.
Please try to put yourself in my position: I have a driver that I care
about, which works fine for a
On 06/05/2014 09:03 PM, Pranith Kumar wrote:
On 06/05/2014 08:34 PM, Peter Hurley wrote:
On 06/05/2014 06:19 PM, Pranith Kumar wrote:
use the documented atomic_cmpxchg instead of __cmpxchg64
This kills the last user of said API in drivers code.
Signed-off-by: Pranith Kumar
---
drivers/io
10 matches
Mail list logo
