On Fri, Feb 17, 2017 at 2:31 PM, Andrew Cooper <andrew.coop...@citrix.com> wrote: > 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. >
Ah, yes, makes sense =) Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel