[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 Fri, Feb 17, 2017 at 2:31 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> 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.
>

Ah, yes, makes sense =)

Tamas

_______________________________________________
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®.