>>> On 15.02.17 at 00:21, <andrew.coop...@citrix.com> wrote: > On 14/02/2017 22:47, Tamas K Lengyel wrote: >> (XEN) Switched to APIC driver x2apic_cluster. >> (XEN) XSM Framework v1.0.0 initialized >> (XEN) Flask: 128 avtab hash slots, 394 rules. >> (XEN) Flask: 128 avtab hash slots, 394 rules. >> (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools >> (XEN) Flask: 12 classes, 394 rules >> (XEN) Flask: Starting in enforcing mode. >> (XEN) xstate: size: 0x340 and states: 0x7 >> (XEN) Intel machine check reporting enabled >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) Platform timer is 14.318MHz HPET >> (XEN) Detected 3392.326 MHz processor. >> (XEN) Initing memory sharing. >> (XEN) alt table ffff82d0802d3f38 -> ffff82d0802d5564 >> (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - 3f >> (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f >> (XEN) >> (XEN) **************************************** >> (XEN) Panic on CPU 0: >> (XEN) Couldn't enable IOMMU and iommu=required/force >> (XEN) **************************************** >> (XEN) >> (XEN) Reboot in five seconds... >> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >> >> As seen in the command line iommu is not set to required or forced. >> Yet Xen thinks it is set to required/force. Has anyone else run into >> this issue? > > This area is a rats nest :( > > The problem is that the APIC setup has chosen to use the x2apic_cluster > driver, which in the Xen code depends on x2APIC, which depends on > interrupt remapping, which depends on an IOMMU. > > (I could have sworn we fixed this before), but the bug is that the APIC > setup shouldn't choose any of the x2apic modes if there isn't an > interrupt remapping capable IOMMU.
And from going over the code I can't see how this would happen, so Tamas, it would be nice if you could add some verbosity to the functions involved. In particular x2apic_bsp_setup() must be getting success (zero) from iommu_enable_x2apic_IR(), yet that function calls iommu_supports_eim(), which ought to produce false through its very first exit path in your case. 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? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
