On 21.10.2020 14:45, Jason Andryuk wrote: > On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 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? Jan _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
