[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0



On 17/02/17 21:28, Tamas K Lengyel wrote:
> On Fri, Feb 17, 2017 at 1:01 PM, Venu Busireddy
> <venu.busireddy@xxxxxxxxxx> 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.wilk@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.