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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan


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