Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, September 6, 2012, 5:03:05 PM, you wrote:

> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>
>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>
>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>
>>>>> Hi Jan,
>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA 
>>>>> fault.
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>> signed-off-by: Wei Wang<wei.wang2@xxxxxxx>
>>>>
>>>>
>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>
>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 
>>>> 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 
>>>> 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id 
>>>> = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id 
>>>> = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>
>>> OK, so they are not interrupt requests. I guess further information from
>>> your system would be helpful to debug this issue:
>>> 1) xl info
>>> 2) xl list
>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>
>> dom14 is not a HVM guest,it's a PV guest.

> Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
> as io page tables. So no-sharept option does not work in this case. PV 
> guests always use separated io page tables. There might be some 
> incorrect mappings on the page tables. I will check this on my side.

> Thanks,
> Wei

In that case it's perhaps mysteriously semi related to a p2m bug in kernels > 
3.4 which freezes guests on my intel box.
Though guests start fine on the amd box with kernels > 3.4, perhaps it does 
give issues for iommu if those are tied somehow.


>> I will try to make a complete package, and try with one pv domain only where 
>> the devices are being passed through just to simplify the setup.
>>
>>
>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>> happened. Did it stop working?
>>
>> Yes it stops working, the video capture just freezes, but the driver doesn't 
>> bail out.
>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in 
>> the guest.
>>
>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>> my RD890 system
>>
>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>> apic=debug iommu=on,verbose,debug,no-sharept
>>
>>> * so, what OEM board you have?)
>>
>> MSI 890FXA-GD70
>>
>>> Also from your log, these lines looks very strange:
>>
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>> = 0x0a06, fault address = 0xc2c2c2c0
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8300
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8340
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8380
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f83c0
>>
>>> * they are just followed by the IO PAGE fault. Do you know where are
>>> they from? Your video card driver maybe?
>>
>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur 
>> without this domain being started.
>>
>>
>>> Thanks,
>>> Wei
>>
>>
>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>
>>>> Thx
>>>>
>>>> --
>>>> Sander
>>
>>
>>
>>
>>





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