[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] FreeBSD Dom0 IOMMU issues



>>> Michael Dexter <editor@xxxxxxxxxxxxxxxxxx> 05/06/15 6:29 PM >>>
>I have been working with Roger Pau Monnà to bring FreeBSD Dom0 support 
>to a production-ready state but we appear to have hit an IOMMU issue.
>
>Hardware: Lenovo ThinkPad T420 i7-2640M CPU @ 2.80GHz with 16GB RAM.
>
>I am attaching my console logs which first show my loader.conf file the 
>DomU .cfg file and then DomU boot with Xorg starting.
>
>In the end I get:
>
>(XEN) ****************************************
>(XEN) Panic on CPU 2:
>(XEN) queue invalidate wait descriptor was not executed
>(XEN) ****************************************

In the end this may be a secondary issue. Namely looking at the more complete
log in your resent mail we see a DMA fault before even starting Dom0. 
Interestingly

(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1d.0
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:1a.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr dacd5000 end_address dacebfff
(XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR:
(XEN) [VT-D]dmar.c:383:  endpoint: 0000:00:02.0
(XEN) [VT-D]dmar.c:676:   RMRR region: base_addr db800000 end_address df9fffff
...
(XEN) [VT-D]iommu.c:859: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:861: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:839: DMAR:[DMA Read] Request device [0000:00:1a.0] fault 
addr dae22000, iommu reg = ffff82c000203000

i.e. the fault address is pretty close the RMRRs, which suggests an issue 
currently
being the subject of an in progress patch series by Elena (firmware failing to 
specify
all exclusion regions via RMRRs).

The faults during guest startup may - as Yang also said - indicate a deeper 
problem,
due to the addresses being clearly out of range. Since you don't seem to be 
passing
through 0000:00:02.0 (the graphics card), it ought to be Dom0 that mis-programs
something, but oddly enough only when a guest is being started. The fact that 
the
majority of the fault instances show the same offending address seems to support
this (or something getting corrupted in the process of creating the guest).

I'm also being puzzled/worried by the "Fault Overflow" logged on each fault. 
I'd have
to check whether the code fails to properly clear that state on its first 
occasion...

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.