Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, Feb 5, 2017 at 1:51 PM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 20, 2017 at 12:30 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 17.01.17 at 16:08, <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>> But fortunately commenting out that line could still reproduce the IOMMU
>>> fault.
>>> I was lucky to capture the full log before it fills up my 100MB ring buffer
>>> (in less than 2 seconds).
>>
>> So here's a first take at a debugging patch. I've tried to limit existing
>> output, so that you'd have better chance of again capturing all
>> interesting messages.
>>
>
> Hi Jan,
> I finally get some spare time to collect the debug info.
> Please find the full log in the attachment.
>
> The mapping appears to be working:
> (XEN) d8: RMRR [cf800,dfa00] mapped cf800
> (XEN) d8: RMRR [cf800,dfa00] mapped cf900
> (XEN) d8: RMRR [cf800,dfa00] mapped cfb00
> (XEN) d8: RMRR [cf800,dfa00] mapped cff00
> (XEN) d8: RMRR [cf800,dfa00] mapped d0700
> (XEN) d8: RMRR [cf800,dfa00] mapped d1700
> (XEN) d8: RMRR [cf800,dfa00] mapped d3700
> (XEN) d8: RMRR [cf800,dfa00] mapped d7700
> (XEN) d8: RMRR [cf800,dfa00] mapped df700
> (XEN) d8: RMRR [cf800,dfa00] alloc -> ffff83013156ffb0
>
> But I'm not sure if the vtd_entries look correct: (Is the 'not
> present' line okay?)
> (XEN) d8: RMRR [cf800,dfa00] mapped cfb00
> (XEN) print_vtd_entries: iommu ffff8304152ec600 dev 0000:00:02.0 gmfn cfb00
> (XEN)     root_entry = ffff820040056000
> (XEN)     root_entry[0] = 201fc6001
> (XEN)     context = ffff820040020000
> (XEN)     context[10] = 1_13956c001
> (XEN)     l3 = ffff820040022000
> (XEN)     l3_index = 3
> (XEN)     l3[3] = 1394ec003
> (XEN)     l2 = ffff820040023000
> (XEN)     l2_index = 7d
> (XEN)     l2[7d] = 0
> (XEN)     l2[7d] not present
>
> Still see the 'Fault overflow' line in the very first fault.
> The fault is about write-access not permitted.
> Is the map read-only here? Or are we looking at the correct PTE?
> (XEN) [VT-D]iommu.c:924: iommu_fault_status: Fault Overflow
> (XEN) [VT-D]iommu.c:926: iommu_fault_status: Primary Pending Fault
> (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr
> cfa00000, iommu reg = ffff82c000201000
> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
> (XEN) print_vtd_entries: iommu ffff8304152ec600 dev 0000:00:02.0 gmfn cfa00
> (XEN)     root_entry = ffff8304152e9000
> (XEN)     root_entry[0] = 201fc6001
> (XEN)     context = ffff830201fc6000
> (XEN)     context[10] = 1_13956c001
> (XEN)     l3 = ffff83013956c000
> (XEN)     l3_index = 3
> (XEN)     l3[3] = 1394ec003
> (XEN)     l2 = ffff8301394ec000
> (XEN)     l2_index = 7d
> (XEN)     l2[7d] = 0
> (XEN)     l2[7d] not present
>

Attraching an xl dmesg log for dom0, which shows a more reasonable vtd_entry.
Does it mean that the mapping wasn't properly setup in the domU case?
But we didn't see a map error in debug log either.

(XEN) d0: RMRR [cf800,dfa00] mapped cfb00
(XEN) print_vtd_entries: iommu ffff8304152ec600 dev 0000:00:02.0 gmfn cfb00
(XEN)     root_entry = ffff8304152e9000
(XEN)     root_entry[0] = 2030ca001
(XEN)     context = ffff8302030ca000
(XEN)     context[10] = 1_2032d1001
(XEN)     l3 = ffff8302032d1000
(XEN)     l3_index = 3
(XEN)     l3[3] = 2030c7003
(XEN)     l2 = ffff8302030c7000
(XEN)     l2_index = 7d
(XEN)     l2[7d] = 2030c5003
(XEN)     l1 = ffff8302030c5000
(XEN)     l1_index = 100
(XEN)     l1[100] = cfb00003

Attachment: dom0.xz
Description: application/xz

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel