- 24 Jan, 2015 1 commit
-
-
Thomas Gleixner authored
Commit 30b8b006 "init: Get rid of x86isms" broke the UP boot on x86_64. That happens because CONFIG_UP_LATE_INIT depends on CONFIG_X86_UP_APIC. X86_UP_APIC is a 32bit only config switch and therefor not set on 64bit UP builds. As a consequence the UP init of the local APIC and the IOAPIC is not called, which results in a boot failure. Make it depend on !SMP && X86_LOCAL_APIC instead. Fixes: 30b8b006 init: Get rid of x86isms Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- 23 Jan, 2015 1 commit
-
-
Thomas Gleixner authored
Commit 7fa1c842 "iommu/irq_remapping: Change variable disable_irq_remap to be static" returns unconditionally success from the irq remapping prepare callback if the iommu can be initialized. The change assumed that iommu_go_to_state(IOMMU_ACPI_FINISHED) returns a failure if irq remapping is not enabled, but thats not the case. The function returns success when the iommu is initialized to the point which is required for remapping to work. The actual state of the irq remapping feature is reflected in the status variable amd_iommu_irq_remap, which is not considered in the return value. The fix is simple: If the iommu_go_to_state() returns success, evaluate the remapping state amd_iommu_irq_remap and reflect it in the return value. Fixes: 7fa1c842 iommu/irq_remapping: Change variable disable_irq_remap to be static Reported-and-tested-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
- 22 Jan, 2015 24 commits
-
-
Thomas Gleixner authored
Get rid of the defined but not used warnings Signed-off-by: -
Thomas Gleixner authored
Now that the APIC bringup is consolidated we can move the setup call for the percpu clock event device to apic_bsp_setup(). Signed-off-by:
-
Thomas Gleixner authored
Extend apic_bsp_setup() so the same code flow can be used for APIC_init_uniprocessor(). Folded Jiangs fix to provide proper ordering of the UP setup. Signed-off-by:
-
Thomas Gleixner authored
The UP related setups for local apic are mangled into smp_sanity_check(). That results in duplicate calls to disable_smp() and makes the code hard to follow. Let smp_sanity_check() return dedicated values for the various exit reasons and handle them at the call site. Signed-off-by:
-
Thomas Gleixner authored
We better provide proper functions which implement the required code flow in the apic code rather than letting the smpboot code open code it. That allows to make more functions static and confines the APIC functionality to apic.c where it belongs. Signed-off-by:
-
Thomas Gleixner authored
The UP local API support can be set up from an early initcall. No need for horrible hackery in the init code. Signed-off-by:
-
Thomas Gleixner authored
Move the code to a different place so we can make other functions inline. Preparatory patch for further cleanups. No change. Signed-off-by:
-
Thomas Gleixner authored
smpboot is very creative with the ways to disable ioapic. smpboot_clear_io_apic() smpboot_clear_io_apic_irqs() and disable_ioapic_support() serve a similar purpose. smpboot_clear_io_apic_irqs() is the most useless of all functions as it clears a variable which has not been setup yet. Aside of that it has the same ifdef mess and conditionals around the ioapic related code, which can now be removed. Signed-off-by:
-
Thomas Gleixner authored
We have proper stubs for the IOAPIC=n case and the setup/enable function have the required checks inside now. Remove the ifdeffery and the copy&pasted conditionals. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>C Acked-by:
-
Thomas Gleixner authored
No point to have the same checks at every call site. Add them to the functions, so they can be called unconditionally. Signed-off-by:
-
Thomas Gleixner authored
To avoid lots of ifdeffery provide proper stubs for setup_IO_APIC(), enable_IO_APIC() and setup_ioapic_dest(). Signed-off-by:
-
Thomas Gleixner authored
No point for a separate header file. Signed-off-by:
-
Thomas Gleixner authored
Use the state information to simplify the disable logic further. Signed-off-by:
-
Thomas Gleixner authored
enable_x2apic() is a convoluted unreadable mess because it is used for both enablement in early boot and for setup in cpu_init(). Split the code into x2apic_enable() for enablement and x2apic_setup() for setup of (secondary cpus). Make use of the new state tracking to simplify the logic. Signed-off-by:
-
Thomas Gleixner authored
There is no point in postponing the hardware disablement of x2apic. It can be disabled right away in the nox2apic setup function. Disable it right away and set the state to DISABLED . This allows to remove all the nox2apic conditionals all over the place. Signed-off-by:
-
Thomas Gleixner authored
Having 3 different variables to track the state is just silly and error prone. Add a proper state tracking variable which covers the three possible states: ON/OFF/DISABLED. We cannot use x2apic_mode for this as this would require to change all users of x2apic_mode with explicit comparisons for a state value instead of treating it as boolean. Signed-off-by:
-
Thomas Gleixner authored
Rename the argument of try_to_enable_x2apic() so the purpose becomes more clear. Make the pr_warning more consistent and avoid the double print of "disabling". Signed-off-by:
-
Thomas Gleixner authored
No point in having try_to_enable_x2apic() outside of the CONFIG_X86_X2APIC section and having inline functions and more ifdefs to deal with it. Move the code into the existing ifdef section and remove the inline cruft. Fixup the printk about not enabling interrupt remapping as suggested by Boris. Signed-off-by:
-
Thomas Gleixner authored
No point in delaying the x2apic detection for the CONFIG_X86_X2APIC=n case to enable_IR_x2apic(). We rather detect that before we try to setup anything there. Signed-off-by:
-
Thomas Gleixner authored
If x2apic_preenabled is not enabled, then disable_x2apic() is not called from various places which results in x2apic_disabled not being set. So other code pathes can happily reenable the x2apic. Signed-off-by:
-
Thomas Gleixner authored
The x2apic_preenabled flag is just a horrible hack and if X2APIC support is disabled it does not reflect the actual hardware state. Check the hardware instead. Signed-off-by:
-
Thomas Gleixner authored
Having several disjunct pieces of code for x2apic support makes reading the code unnecessarily hard. Move it to one ifdeffed section. Signed-off-by:
-
Thomas Gleixner authored
No point in having a static variable around which is always 0. Let the compiler optimize code out if disabled. Signed-off-by:
-
Thomas Gleixner authored
enable_IR_x2apic() grew a open coded x2apic detection. Implement a proper helper function which shares the code with the already existing x2apic_enabled(). Made it use rdmsrl_safe as suggested by Boris. Signed-off-by:
-
- 15 Jan, 2015 14 commits
-
-
Jiang Liu authored
Refine code by normailizing the way to detect whether IR is enabled. Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Tested-by:
Joerg Roedel <joro@8bytes.org> Cc: Tony Luck <tony.luck@intel.com> Cc: iommu@lists.linux-foundation.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Link: http://lkml.kernel.org/r/1420615903-28253-17-git-send-email-jiang.liu@linux.intel.comSigned-off-by:
-
Jiang Liu authored
Change variable disable_irq_remap to be static and simplify the code. Signed-off-by:
-
Jiang Liu authored
Assign intel_irq_remap_ops to remap_ops only if intel_irq_remap_ops.prepare() succeeds. Signed-off-by:
-
Jiang Liu authored
Simplify irq_remapping code by killing irq_remapping_supported() and related interfaces. Joerg posted a similar patch at https://lkml.org/lkml/2014/12/15/490, so assume an signed-off from Joerg. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Tested-by:
-
Joerg Roedel authored
This allows to get rid of the irq_remapping_supported() function and all its call-backs into the Intel and AMD IOMMU drivers. Signed-off-by:
-
Jiang Liu authored
When interrupt remapping hardware is not in X2APIC, CPU X2APIC mode will be disabled if: 1) Maximum CPU APIC ID is bigger than 255 2) hypervisior doesn't support x2apic mode. But we should only check whether hypervisor supports X2APIC mode when hypervisor(CONFIG_HYPERVISOR_GUEST) is enabled, otherwise X2APIC will always be disabled when CONFIG_HYPERVISOR_GUEST is disabled and IR doesn't work in X2APIC mode. Signed-off-by:
-
Jiang Liu authored
Currently if CPU supports X2APIC, IR hardware must work in X2APIC mode or disabled. Change the code to support IR working in XAPIC mode when CPU supports X2APIC. Then the CPU APIC driver will decide how to handle such as configuration by: 1) Disabling X2APIC mode 2) Forcing X2APIC physical mode This change also fixes a live locking when 1) BIOS enables CPU X2APIC 2) DMAR table disables X2APIC mode or IR hardware doesn't support X2APIC with following messages: [ 37.863463] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2 [ 37.863463] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry [ 37.879372] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2 [ 37.879372] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry [ 37.895282] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2 [ 37.895282] INTR-REMAP:[fault reason 36] Detected reserved fields in the IRTE entry [ 37.911192] dmar: INTR-REMAP: Request device [[f0:1f.7] fault index 2 Signed-off-by:
-
Joerg Roedel authored
IRQ remapping is only supported when all IOMMUs in the system support it. So check if all IOMMUs in the system support IRQ remapping before doing the allocations. [Jiang] 1) Rebased to v3.19. 2) Remove redundant check of ecap_ir_support(iommu->ecap) in function intel_enable_irq_remapping(). Signed-off-by:
-
Jiang Liu authored
Prepare for killing function irq_remapping_supported() by moving code from intel_irq_remapping_supported() into intel_prepare_irq_remapping(). Combined with patch from Joerg at https://lkml.org/lkml/2014/12/15/487, so assume an signed-off from Joerg. Signed-off-by:
-
Jiang Liu authored
If remapping is in XAPIC mode, the setup code just skips X2APIC initialization without checking max CPU APIC ID in system, which may cause problem if system has a CPU with APIC ID bigger than 255. Handle IR in XAPIC mode the same way as if remapping is disabled. [ tglx: Split out from previous patch ] Signed-off-by:
-
Jiang Liu authored
Refine enable_IR_x2apic() and related functions for better readability. [ tglx: Removed the XAPIC mode change and split it out into a seperate patch. Added comments. ] Signed-off-by:
-
Jiang Liu authored
X2APIC will be disabled if user specifies "nox2apic" on kernel command line, even when x2apic_preenabled is true. So correctly detect X2APIC status by using x2apic_enabled() instead of x2apic_preenabled. Signed-off-by:
-
Jiang Liu authored
Local variable x2apic_enabled has been assigned to but never referred, so kill it. Signed-off-by:
-
Jiang Liu authored
When kernel doesn't support X2APIC but BIOS has enabled X2APIC, system may panic or hang without useful messages. On the other hand, it's hard to dynamically disable X2APIC when CONFIG_X86_X2APIC is disabled. So panic with a clear message in such a case. Now system panics as below when X2APIC is disabled and interrupt remapping is enabled: [ 0.316118] LAPIC pending interrupts after 512 EOI [ 0.322126] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.368655] Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC [ 0.378300] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0+ #340 [ 0.385300] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIN1.86B.0051.L05.1406240953 06/24/2014 [ 0.396997] ffff88046dc03000 ffff88046c307dd8 ffffffff8179dada 00000000000043f2 [ 0.405629] ffffffff81a92158 ffff88046c307e58 ffffffff8179b757 0000000000000002 [ 0.414261] 0000000000000008 ffff88046c307e68 ffff88046c307e08 ffffffff813ad82b [ 0.422890] Call Trace: [ 0.425711] [<ffffffff8179dada>] dump_stack+0x45/0x57 [ 0.431533] [<ffffffff8179b757>] panic+0xc1/0x1f5 [ 0.436978] [<ffffffff813ad82b>] ? delay_tsc+0x3b/0x70 [ 0.442910] [<ffffffff8166fa2c>] panic_if_irq_remap+0x1c/0x20 [ 0.449524] [<ffffffff81d73645>] setup_IO_APIC+0x405/0x82e [ 0.464979] [<ffffffff81d6fcc2>] native_smp_prepare_cpus+0x2d9/0x31c [ 0.472274] [<ffffffff81d5d0ac>] kernel_init_freeable+0xd6/0x223 [ 0.479170] [<ffffffff81792ad0>] ? rest_init+0x80/0x80 [ 0.485099] [<ffffffff81792ade>] kernel_init+0xe/0xf0 [ 0.490932] [<ffffffff817a537c>] ret_from_fork+0x7c/0xb0 [ 0.497054] [<ffffffff81792ad0>] ? rest_init+0x80/0x80 [ 0.502983] ---[ end Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC System hangs as below when X2APIC and interrupt remapping are both disabled: [ 1.102782] pci 0000:00:02.0: System wakeup disabled by ACPI [ 1.109351] pci 0000:00:03.0: System wakeup disabled by ACPI [ 1.115915] pci 0000:00:03.2: System wakeup disabled by ACPI [ 1.122479] pci 0000:00:03.3: System wakeup disabled by ACPI [ 1.132274] pci 0000:00:1c.0: Enabling MPC IRBNCE [ 1.137620] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled [ 1.145239] pci 0000:00:1c.0: System wakeup disabled by ACPI [ 1.151790] pci 0000:00:1c.7: Enabling MPC IRBNCE [ 1.157128] pci 0000:00:1c.7: Intel PCH root port ACS workaround enabled [ 1.164748] pci 0000:00:1c.7: System wakeup disabled by ACPI [ 1.171447] pci 0000:00:1e.0: System wakeup disabled by ACPI [ 1.178612] acpiphp: Slot [8] registered [ 1.183095] pci 0000:00:02.0: PCI bridge to [bus 01] [ 1.188867] acpiphp: Slot [2] registered With this patch applied, the system panics in both cases with a proper panic message. Signed-off-by:
-
