On Wed, Oct 21, 2020 at 8:53 AM Jan Beulich <jbeul...@suse.com> wrote: > > On 21.10.2020 14:45, Jason Andryuk wrote: > > On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné <roger....@citrix.com> > > wrote: > >> Hm, it's hard to tell what's going on. My limited experience with > >> IOMMU faults on broken systems there's a small range that initially > >> triggers those, and then the device goes wonky and starts accessing a > >> whole load of invalid addresses. > >> > >> You could try adding those manually using the rmrr Xen command line > >> option [0], maybe you can figure out which range(s) are missing? > > > > They seem to change, so it's hard to know. Would there be harm in > > adding one to cover the end of RAM ( 0x04,7c80,0000 ) to ( > > 0xff,ffff,ffff )? Maybe that would just quiet the pointless faults > > while leaving the IOMMU enabled? > > While they may quieten the faults, I don't think those faults are > pointless. They indicate some problem with the software (less > likely the hardware, possibly the firmware) that you're using. > Also there's the question of what the overall behavior is going > to be when devices are permitted to access unpopulated address > ranges. I assume you did check already that no devices have their > BARs placed in that range?
Isn't no-igfx already letting them try to read those unpopulated addresses? Looks like all PCI BARs are below 4GB. The graphics ones are: 00:02.0 VGA compatible controller: Intel Corporation Device 3ea0 (rev 02) (prog-if 00 [VGA controller]) Subsystem: Dell Device 08b9 Flags: bus master, fast devsel, latency 0, IRQ 177 Memory at cb000000 (64-bit, non-prefetchable) [size=16M] Memory at 80000000 (64-bit, prefetchable) [size=256M] Yes, I agree the faults aren't pointless. I'm wondering if it's something with the i915 driver or hardware having assumptions that aren't met by Xen swiotlb. Regards, Jason _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx