search for: __stop_this_cpu

... by the call to hpet_disable() added in the immediately preceding patch. In order to retain the behavior intended by c/s 23776:0ddb4481f883, implement one of the alternative options pointed out there: remove CPUs from the online map in __stop_this_cpu() (and hence doing so in stop_this_cpu() is no longer needed). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/crash.c +++ b/xen/arch/x86/crash.c @@ -61,9 +61,6 @@ static void nmi_shootdown_cpus(void) local_irq_disable(); - if ( hpet_broadcast_is_available() )...

...mpleting it in the first place. * Set up another NMI at the LAPIC. Even when the LAPIC has been disabled, the ID and command registers are still usable. As a result, we can deliberately queue up a new NMI to re-interrupt us later if NMIs get unlatched. Because of the call to __stop_this_cpu(), we have to hand craft self_nmi() to be safe from General Protection Faults. * Fall into infinite loop. machine_kexec() will: * Swap the MCE handlers to be a nop. We cannot prevent MCEs from being delivered when we pass off to the crash kernel, and the less Xen context is bein...

...mu available xen crashes. This can happen for example when panic(...) is called as introduced with the patch "x86-64: detect processors subject to AMD erratum #121 and refuse to boot" since xen 4.1.3, resulting in find_iommu_for_device() to be called in the context of disable_IO_APIC() / __stop_this_cpu(). This patch fixes this by keeping the iommu disabled until iommu_setup() is entered. Originally-by: Ronny Hegewald <ronny.hegewald@online.de> In order for iommu_enable to be off initially, iommu_supports_eim() must not depend on it anymore, nor must acpi_parse_dmar(). The former in turn...

...the following stacktrace: find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt enable_8259_A_irq do_IRQ printk_start_of_line acpi_os_printf io_apic_write __ioapic_write_entry ioapic_write_entry __clear_IO_APIC_pin clear_IO_APIC disable_IO_APIC __stop_this_cpu smp_send_stop machine_restart panic tasklet_schedule_on_cpu display_cacheinfo init_amd generic_identify identify_cpu _start_xen _high_start This patch fixes this by keeping the iommu disabled until iommu_setup() is entered. Signed-off-by: Ronny Hegewald@online.de...

...appears (i typed it down from screen, so it might contain typos) find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt enable_8259_A_irq do_IRQ printk_start_of_line acpi_os_printf io_apic_write __ioapic_write_entry ioapic_write_entry __clear_IO_APIC_pin clear_IO_APIC disable_IO_APIC __stop_this_cpu smp_send_stop machine_restart panic tasklet_schedule_on_cpu display_cacheinfo init_amd generic_identify identify_cpu _start_xen _high_start Panic on CPU 0: Xen BUG at pci_amd_iommu.c:33 ===== The patch in the next mail fixes the problem for me and the intended panic- message appears.

...6/smp.c @@ -19,6 +19,7 @@ #include <asm/mc146818rtc.h> #include <asm/flushtlb.h> #include <asm/hardirq.h> +#include <asm/hpet.h> #include <asm/hvm/support.h> #include <mach_apic.h> @@ -375,6 +376,7 @@ void smp_send_stop(void) local_irq_disable(); __stop_this_cpu(); disable_IO_APIC(); + hpet_disable(); local_irq_enable(); } --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -377,7 +377,7 @@ static int __init init_hpet(struct platf static void resume_hpet(struct platform_timesource *pts) { - hpet_resume(); + hpet_resume(NULL);...

...(), mask) ) { local_irq_disable(); - __smp_call_function_interrupt(); + smp_call_function_interrupt(); local_irq_enable(); } - - while ( !cpumask_empty(&call_data.selected) ) - cpu_relax(); - - out: - spin_unlock(&call_lock); } void __stop_this_cpu(void) @@ -390,36 +339,9 @@ void event_check_interrupt(struct cpu_user_regs *regs) this_cpu(irq_count)++; } -static void __smp_call_function_interrupt(void) -{ - void (*func)(void *info) = call_data.func; - void *info = call_data.info; - unsigned int cpu = smp_processor_id(); - -...

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>