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
