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

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



BTW, before I generate more verbose && complete debug log, just want to update that I also see the following in dom0 (without attempting any pass-through to the IGD device)
But this time the log is not flooding at all. Not sure if this is relevant to what I see from the domU with pci pass-through.

(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 7300000000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 7300000000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 7300000000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 7300000000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr 7300000000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set


On Mon, Jan 16, 2017 at 11:15 PM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote:


On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>> On 16.01.17 at 14:43, <firemeteor@users.sourceforge.net> wrote:
> On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 16.01.17 at 10:25, <firemeteor@users.sourceforge.net> wrote:
> The fault log itself is really flooding. With a small 4MB ring buffer, I
> wasn't able to capture how it begins.

If you can't set up a serial console, grow the ring buffer.
Larger ring buffer seems to be the only option to me.
Seems that 'serial console' needs to be something physical.
 
> That RMRR setup has changed dramatically (from being basically
>> non-existent in the older versions), especially for USB devices (I
>> don't think I can conclude what type of device 0000:02:00.0 is).
>> There are messages logged with various failures in that process,
>> but some would be issued by debug hypervisors only. A good
>> first step (before possibly doing actual code instrumentation)
>> would therefore be to retry with a debug hypervisor, and post
>> the full log (huge amounts of trailing IOMMU fault messages may
>> of course be stripped as long as they're sufficiently similar, to
>> keep the overall log size manageable).
>>
> I can give it a try when I get some spare time.
> Could you show me the flow to build a debug hypervisor and the most
> relevant debug knobs to avoid log flooding?

For building a debug hypervisor, all you need to do is set
CONFIG_DEBUG=y in xen/.config. I don't think there are any
knobs to avoid log flooding - after all you've asked for the
verbosity via "iommu=verbose,debug".
I assume I do not need to redo the ./configure here.
And I assume the xen/.config here refers to the root of the repos instead of the xen.git/xen subdirectory?
I couldn't find obvious debug knob in the gcc command-line, even though the build is with -O1.
 


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

 


Rackspace

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