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. <firemet...@users.sourceforge.net> wrote: > > > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 16.01.17 at 14:43, <firemet...@users.sourceforge.net> wrote: >> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich <jbeul...@suse.com> wrote: >> >> >>> On 16.01.17 at 10:25, <firemet...@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@lists.xen.org https://lists.xen.org/xen-devel
