lkml.org 
[lkml]   [2019]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v1 4/9] iommu/vt-d: Add bounce buffer API for domain map/unmap
From
Date
On 19/03/2019 07:59, Lu Baolu wrote:
> Hi Christoph,
>
> On 3/14/19 12:10 AM, Christoph Hellwig wrote:
>> On Wed, Mar 13, 2019 at 10:31:52AM +0800, Lu Baolu wrote:
>>> Hi again,
>>>
>>> On 3/13/19 10:04 AM, Lu Baolu wrote:
>>>> Hi,
>>>>
>>>> On 3/13/19 12:38 AM, Christoph Hellwig wrote:
>>>>> On Tue, Mar 12, 2019 at 02:00:00PM +0800, Lu Baolu wrote:
>>>>>> This adds the APIs for bounce buffer specified domain
>>>>>> map() and unmap(). The start and end partial pages will
>>>>>> be mapped with bounce buffered pages instead. This will
>>>>>> enhance the security of DMA buffer by isolating the DMA
>>>>>> attacks from malicious devices.
>>>>>
>>>>> Please reuse the swiotlb code instead of reinventing it.
>>>>>
>>>
>>> Just looked into the code again. At least we could reuse below
>>> functions:
>>>
>>> swiotlb_tbl_map_single()
>>> swiotlb_tbl_unmap_single()
>>> swiotlb_tbl_sync_single()
>>>
>>> Anything else?
>>
>> Yes, that is probably about the level you want to reuse, given that the
>> next higher layer already has hooks into the direct mapping code.
>>
>
> I am trying to change my code to reuse swiotlb. But I found that swiotlb
> might not be suitable for my case.
>
> Below is what I got with swiotlb_map():
>
> phy_addr        size    tlb_addr
> --------------------------------
> 0x167eec330     0x8     0x85dc6000
> 0x167eef5c0     0x40    0x85dc6800
> 0x167eec330     0x8     0x85dc7000
> 0x167eef5c0     0x40    0x85dc7800
>
> But what I expected to get is:
>
> phy_addr        size    tlb_addr
> --------------------------------
> 0x167eec330     0x8     0xAAAAA330
> 0x167eef5c0     0x40    0xBBBBB5c0
> 0x167eec330     0x8     0xCCCCC330
> 0x167eef5c0     0x40    0xDDDDD5c0
>
> , where 0xXXXXXX000 is the physical address of a bounced page.
>
> Basically, I want a bounce page to replace a leaf page in the vt-d page
> table, which maps a buffer with size less than a PAGE_SIZE.

I'd imagine the thing to do would be to factor out the slot allocation
in swiotlb_tbl_map_single() so that an IOMMU page pool/allocator can be
hooked in as an alternative.

However we implement it, though, this should absolutely be a common
IOMMU thing that all relevant DMA backends can opt into, and not
specific to VT-d. I mean, it's already more or less the same concept as
the PowerPC secure VM thing.

Robin.

\
 
 \ /
  Last update: 2019-03-19 12:22    [W:0.192 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site