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

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



> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, February 16, 2017 5:32 PM
> 
> >>> On 15.02.17 at 20:30, <tamas.k.lengyel@xxxxxxxxx> wrote:
> > 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"
> 
> 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.

Thanks
Kevin

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

 


Rackspace

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