[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 15.02.17 at 00:21, <andrew.cooper3@xxxxxxxxxx> 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?

iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default"


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.