Re: Unable to boot Xen 4.8 with iommu=0

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@intel.com> 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@suse.com>
> > 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?
> 
> Tamas
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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