On 17/02/17 21:28, Tamas K Lengyel wrote: > On Fri, Feb 17, 2017 at 1:01 PM, Venu Busireddy > <venu.busire...@oracle.com> wrote: >> On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote: >>> On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote: >>>> On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk >>>> <konrad.w...@oracle.com> wrote: >>>>> . snip.. >>>>>>>>> Given this commit is pretty old, I'm also curious why it's only >>>>>>>>> reported >>>>>>>>> on 4.8. Tamas, did you succeed with iommu=0 pre 4.8, or 4.8 happens >>>>>>>>> to be the one upon which you first tried iommu=0 on a platform >>>>>>>>> supporting >>>>>>>>> interrupt remapping? >>>>>>>> It just happens to be the one I tried. VT-d was spamming my console >>>>>>>> with faults like this: >>>>>>>> >>>>>>>> (XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr >>>>>>>> 277e28000, iommu reg = ffff82c000201000 >>>> ffff82c000201000 >>>>>>>> (XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set >>>>>>>> >>>>>>>> So I figured I can just turn it off to clean up my console. I still >>>>>>>> don't know what these VT-d faults are about.. >>>>>>> What is the 0:02.0 device? Is it being passed in to your guest? >>>>>> Nope, there is no pass-through to any guests. The device is: >>>>>> >>>>>> 00:02.0 Display controller: Intel Corporation 2nd Generation Core >>>>>> Processor Family Integrated Graphics Controller (rev 09) >>>>> Let me guess, you have an SandyBridge motherboard and were using >>>>> Intel AMT? >>>> Correct. >>>> >>>>> I see those all the time on that box (and I think my Haswell >>>>> one too). The best I could narrow it down was that the card decided that >>>>> certain area should be in the RMRR regions. With Venu/Elen's patch >>>>> in (see 431685e8deb660976d8e986c41a647944e410c6c) you should be able >>>>> to provide an rmrr paramater to include these addresses. >>>> Some more information on how to use that flag would be valuable.. I >>>> tried "rmrr=270000000-280000000=00:02.0" to no avail and I really have >>>> no idea what I'm doing here =) >>> CC-ing Elena and Venu who I hope can help you with this. >>> >>> You may want to provide the full 'xl dmesg' as the 'rmrr' should have >>> outputted some details.. >> Tamas, >> >> While 'xl dmesg' and the output from the serial console will certainly >> help, it appears that you may have already provided the info needed. There >> may be other devices than 0:02.0 that have problems, but let us assume >> that it is the only device. >> >> Your change to xen command line is incorrect. The correct option to add >> to the xen command line is: >> >> rmrr=0x277e28=0:00:02.0 > I see, so it has to be a page and not an address.. OTOH the problem > with specifying 0x277e28 is that the fault address seem to change > every time I reboot the machine. I'm not sure where that range is > coming from but it always seems to be between 270000000-280000000.
Looking at the parsing code, ranges work fine but you need to use 0x for hex addresses, or the address will be interpreted as decimal. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
