RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

[Liu, Yi L]

> -----Original Message-----
> From: Bob Liu [mailto:liubo95@xxxxxxxxxx]
> Sent: Thursday, October 12, 2017 6:08 PM
> To: Liu, Yi L <yi.l.liu@xxxxxxxxx>; Jean-Philippe Brucker <jean-
> philippe.brucker@xxxxxxx>; Joerg Roedel <joro@xxxxxxxxxx>
> Cc: Lan, Tianyu <tianyu.lan@xxxxxxxxx>; Liu, Yi L <yi.l.liu@xxxxxxxxxxxxxxx>; Greg
> Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Wysocki, Rafael J
> <rafael.j.wysocki@xxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>;
> iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; David Woodhouse <dwmw2@xxxxxxxxxxxxx>
> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function
> 
> On 2017/10/12 17:50, Liu, Yi L wrote:
> >
> >
> >> -----Original Message-----
> >> From: Bob Liu [mailto:liubo95@xxxxxxxxxx]
> >> Sent: Thursday, October 12, 2017 5:39 PM
> >> To: Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx>; Joerg
> >> Roedel <joro@xxxxxxxxxx>; Liu, Yi L <yi.l.liu@xxxxxxxxx>
> >> Cc: Lan, Tianyu <tianyu.lan@xxxxxxxxx>; Liu, Yi L
> >> <yi.l.liu@xxxxxxxxxxxxxxx>; Greg Kroah-Hartman
> >> <gregkh@xxxxxxxxxxxxxxxxxxx>; Wysocki, Rafael J
> >> <rafael.j.wysocki@xxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>;
> >> iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; David Woodhouse
> >> <dwmw2@xxxxxxxxxxxxx>
> >> Subject: Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API
> >> function
> >>
> >> On 2017/10/11 20:48, Jean-Philippe Brucker wrote:
> >>> On 11/10/17 13:15, Joerg Roedel wrote:
> >>>> On Wed, Oct 11, 2017 at 11:54:52AM +0000, Liu, Yi L wrote:
> >>>>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea?
> >>>>
> >>>> It's short for IO Virtual Memory, basically a replacement term for 'svm'
> >>>> that is not ambiguous (afaik) and not specific to Intel.
> >>>
> >>> I wonder if SVM originated in OpenCL first, rather than intel?
> >>> That's why I'm using it, but it is ambiguous. I'm not sure IOVM is
> >>> precise enough though, since the name could as well be used without
> >>> shared tables, for classical map/unmap and IOVAs. Kevin Tian
> >>> suggested SVA "Shared Virtual Addressing" last time, which is a
> >>> little more clear than SVM and isn't used elsewhere in the kernel either.
> >>>
> >>
> >> The process "vaddr" can be the same as "IOVA" by using the classical
> >> map/unmap way.
> >> This is also a kind of share virtual memory/address(except have to
> >> pin physical memory).
> >> How to distinguish these two different implementation of "share
> >> virtual memory/address"?
> >>
> > [Liu, Yi L] Not sure if I get your idea well. Process "vaddr" is owned
> > by process and maintained by mmu, while "IOVA" is maintained by iommu.
> > So they are different in the way they are maintained. Since process
> > "vaddr" is maintained by mmu and then used by iommu, so we call it shared virtual
> memory/address. This is how "shared" term comes.
> 
> I think from the view of application, the share virtual memory/address(or Nvidia-
> CUDA unify virtual address) is like this:
> 
> 1. vaddr = malloc(); e.g vaddr=0x10000
> 2. device can get the same data(accessing the same physical memory) through same
> address e.g 0x10000, and don't care about it's a vaddr or IOVA..
> (actually in Nvidia-cuda case, the data will be migrated between system-ddr and gpu-
> memory, but the vaddr is always the same for CPU and GPU).
> 
> So there are two ways(beside Nvidia way) to implement this requirement:
> 1)
> get the physical memory of vaddr;
> dma_map the paddr to iova;
> If we appoint iova = vaddr (e.g iova can be controlled by the user space driver
> through vfio DMA_MAP), This can also be called share virtual address between CPU
> process and device..

[Liu, Yi L] I see. Thx for raising it. I think this is a software way to get data shared between
process and device. However, it's not sharing the virtual address space since device would
still use iova to do access memory. So it should be another story.

Regards,
Yi L

> 2)
> The second way is what this RFC did.
>