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 11:48 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Fri, Feb 17, 2017 at 11:42:20AM -0700, Tamas K Lengyel wrote:
>> On Thu, Feb 16, 2017 at 11:53 PM, Tian, Kevin <kevin.tian@xxxxxxxxx> wrote:
>> >> From: Tian, Kevin
>> >> Sent: Friday, February 17, 2017 11:35 AM
>> >> > >>
>> >> > >> Or wait - do you have the same issue if you use
>> >> > >> "iommu=no,no-intremap"? In which case the problem would be
>> >> > >> that "iommu=no" should clear more than just "iommu_enable", or
>> >> > >> code checking iommu_intremap early (before iommu_setup()
>> >> > >> manages to clear it in the case here) would need to made look at
>> >> > >> both variables. Oddly enough acpi_parse_dmar() only bails if
>> >> > >> both variables are clear, which suggests to me that
>> >> > >> iommu_enable is intended to have two different meanings in
>> >> > >> different contexts (master flag vs. controlling just DMA
>> >> > >> remapping). Kevin, Feng - any thoughts here?
>> >> > >
>> >> > > iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default"
>> >> >
>> >> > Thanks for confirming.
>> >> >
>> >> > Kevin, Feng, we now depend on your input regarding the intentions
>> >> > with the two variables.
>> >> >
>> >>
>> >> Feng just left Intel. Let me take a look at code to understand the
>> >> rationale behind.
>> >>
>> >
>> > Jan, looks it's caused by your change back to 2012:
>> >
>> > commit 7a8f6d0607a38c64506b4e8b473d955bf8e2a71f
>> > Author: Jan Beulich <jbeulich@xxxxxxxx>
>> > Date:   Fri Nov 2 17:15:30 2012 +0100
>> >
>> > Before that iommu_enable was the master flag consistently. I'm still
>> > trying to understand the background and you may help elaborate if
>> > still something in your memory.
>> >
>> > I agree we should stick to one meaning after clearing up above issue.
>> >
>> > 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
>> (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)

Tamas

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