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.t...@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 <jbeul...@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
