lkml.org 
[lkml]   [2016]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] iommu/amd: Fix unity mapping initialization race
From
Date


On 2016年07月11日 15:19, Joerg Roedel wrote:
> On Sun, Jul 10, 2016 at 07:40:53PM +0800, Wan Zongshun wrote:
>> Do you mean we need enable the V and TV bits to DTE entry after all
>> DTEs tables were initialized completely?
>
> Yes, this is what my patch does and what fixes the bug that was
> reported on machines which have unity-mapping entries.

Okay, this patch should also better to general case not only unity-mapping.

How about the interrupt remap function? Do we need same considering for
IV bit enable for interrupt remap?

>
>> I checked this function 'init_device_table_dma', and find it just set
>> V and TV bit, to set translation info valid and DTE bits127:1 valid.
>
> Right, if no other bits are set this blocks all DMA from the gives
> device-id.

Sorry, why you still say this 'init_device_table_dma' can block DMA?
I just think this function will enable DMA transfer, since we set the V
and TV bits, right? or I misunderstand what "block DMA" mean?

>
>> So I just think all things it should to do are to allow DMA access,
>> GPA-to-SPA translation should be active, why you add function
>> comments below is to not allow DMA access and suppress all page
>> faults?
>>
>> /*
>> * Init the device table to not allow DMA access for devices and
>> * suppress all page faults
>> */
>
> Yeah, that comment needs to be updated. Not all DMA is blocked and
> page-faults are not suppressed at all. Thanks for noticing.
>
>
>
> Joerg
>
>

\
 
 \ /
  Last update: 2016-07-11 12:01    [W:0.949 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site