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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

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.

>
> For the RMRR specification to work, apart from changing the Xen command
> line appropriately, you will also need the corresponding patch applied to
> your Xen image. The patch has been pushed upstream, but is only available
> in 4.9. Did you backport that change and rebuilt your Xen image with
> it? Unless you do that, the Xen command line changes won't work.

Ah, no, I thought it was already part of Xen 4.8.. I'll check with 4.9
unstable in a bit.

Thanks!
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel