lkml.org 
[lkml]   [2014]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] iommu/vt-d: Use the SIRTP when enabling remapping
On 9/10/2014 1:56 AM, Jan Kiszka wrote:
> On 2014-09-09 23:11, Nathan Zimmer wrote:
>> The previous change (iommu/vt-d: Don't store SIRTP request) to this area
>> caused a crash in our simulator. In particular is seems that by the time a
>> UART interrupt is sent through the system, we don't see interrupt remapping
>> to be enabled. So the interrupt does not get translated to a logical
>> interrupt and crashes.
>>
>> OR'ing the SIRTP request to make sure it is seen but hopefully not sticky.
>> This seems like a clean fix, at least on our simulator; if you don't agree,
>> our simulator guy will take a closer look at our iommu model.
>
> Check the VT-d spec (6.7, Set Interrupt Remapping Table Pointer
> Operation): "Software must always follow the interrupt-remapping table
> pointer set operation with a global invalidate of the IEC to ensure
> hardware references the new structures *before* enabling interrupt
> remapping." There is also (command register description): "If multiple
> control fields in this register need to be modified, software must
> serialize the modifications through multiple writes to this register."
> This, in combination with the command registers description of bits 24
> and 25 strongly suggests that your model is broken.

Thanks, Jan. I'll read up on it. Still working out some kinks with
the relatively new IOMMU/interrupt-remapping logic which we added over
the last 18 months or so. Sorry for any distraction, and thanks for the
help/info.
Gary

>
>>
>> Found testing on our simulator, not real hardware.
>
> Funnily, the original issue was found by the QEMU model of VT-d that
> used to take the last cited sentence very strictly (I asked to remove it
> due to the preexisting Linux versions).
>
> Jan
>



\
 
 \ /
  Last update: 2014-09-10 10:41    [W:0.075 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site