search for: identify_cpu

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into i...

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into i...

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

...hitecture-dependent bugs. + * + * Needs: + * void check_bugs(void); + */ + +#include <linux/kernel.h> +#include <asm/alternative.h> +#include <asm/processor.h> +#include <asm/i387.h> +#include <asm/msr.h> +#include <asm/pda.h> + +void __init check_bugs(void) +{ + identify_cpu(&boot_cpu_data); +#if !defined(CONFIG_SMP) + printk("CPU: "); + print_cpu_info(&boot_cpu_data); +#endif + alternative_instructions(); +} =================================================================== --- a/include/asm-x86_64/alternative.h +++ b/include/asm-x86_64/alternative....

...hitecture-dependent bugs. + * + * Needs: + * void check_bugs(void); + */ + +#include <linux/kernel.h> +#include <asm/alternative.h> +#include <asm/processor.h> +#include <asm/i387.h> +#include <asm/msr.h> +#include <asm/pda.h> + +void __init check_bugs(void) +{ + identify_cpu(&boot_cpu_data); +#if !defined(CONFIG_SMP) + printk("CPU: "); + print_cpu_info(&boot_cpu_data); +#endif + alternative_instructions(); +} =================================================================== --- a/include/asm-x86_64/alternative.h +++ b/include/asm-x86_64/alternative....

...tart_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 --- xen/drivers/passthrough/iommu.c.org 2012-10-05 03:38:33.000000000 +0000 +++ xen/drivers/passthrough/iommu.c 2012-10-17 22:58:07.00000000...

...: IBM x3400 (MT7976) with 2 Xeon E5310 and 4GB of RAM xen version: 4.01 Enterprise problem: Installation CD doesn''t boot, it locks on this error: --------------------------------------------------------------------------- Xen call trace shows codes about: vmx_ini_vmcs_config start_vmx identify_cpu smp_store_cpu_info smp_callin start_secondary ********************* Panic on CPU n: Xen BUG at vncs.c:124 ********************* Reboot in five seconds... --------------------------------------------------------------------------- screenshot of error at: http://valtellinux.it/xen/xenbug.jpg 400k...

Hi, All: Does the guest OS need to detect hyperthreading? One would think that the hypervisor decides what to schedule on what CPU, and the job of the guest is not to be too smart for its own good. So, my first reaction was to comment detect_ht() altogether. Fedora Core 5 has the code in detect_ht(), though I have no idea what the results of this are on HT CPUs, if they match the reality.

...e. Apparently there are patches for this error, which only affects intel: http://www.gossamer-threads.com/lists/xen/devel/185593 For logging the output is the same as in the above thread: Xen call trace ========== xsave_init + 0x6d/0x1f0 init_intel + 0x13d/0x380 generic_identity + 0x39/0x190 identify_cpu + 0xe2/0x250 __start_xen + 0x2ec6/0x3340 __high_start + 0xa1/0xa3 Error message: =========== Panic on CPU 0: Xen BUG at i387.c:159 For more info: http://wiki.xensource.com/xenwiki/Xen4.0 In Xen 4.0.1 there's a bug in HVM guest save/restore/livemigration on Intel CPUs, related to XSAVE fe...

...imer_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.

...being aware of the address range used it cannot possibly reserve the space in E820 or ACPI resources. Hence we need to manually insert the range into the E820 table, and enable the range only when the insertion actually works without conflict. Further, the actual enabling of the space is done from identify_cpu(), which means that acpi_mmcfg_init() muts be called after that function (and hance should not be called from acpi_boot_init()). Otherwise, Dom0 would be able to use MMCFG, but Xen wouldn''t. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/arch/x86/acpi/boot.c +++ b/xen/a...

...032a00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 ff1bb080 (XEN) Xen call trace: (XEN) [<ff146c26>] amd_mcheck_init+0x26/0xe0 (XEN) [<ff1464cc>] identify_cpu+0x1fc/0x210 (XEN) [<ff1b3fbe>] subarch_init_memory+0x4e/0x70 (XEN) [<ff1ad999>] __start_xen+0xab9/0x1380 (XEN) [<ff1a1fff>] e820nr+0x0/0x4 (XEN) [<ff1a15ff>] e820map+0x0/0xa00 (XEN) [<ff10006c>] __high_start+0x58/0x5a (XEN) (XEN) (XEN) *************...

...onvert-pda-into-the-percpu-section.patch i386-cleanups-to-help-using-per-cpu-variables-from-asm.patch percpu-define-per_cpu_offset.patch fix-uniproc-gdt-bugs.patch Percpu and GDT fixes. x86-map-enough-initial-memory.patch Fix head.S to map enough memory. cleanup-cleanup-asm-bugs_h.patch cleanup-identify_cpu-fix.patch This is the pair I tried to post yesterday, but they got interrupted by an network outage. They basically add a little more cleanup, and move a misplaced hunk. cleanup-cleanup-asm-bugs_h.patch should go after/roll into the clean-up-asm-(i386|x86_64)-bugs_h patches, and cleanup-iden...

...onvert-pda-into-the-percpu-section.patch i386-cleanups-to-help-using-per-cpu-variables-from-asm.patch percpu-define-per_cpu_offset.patch fix-uniproc-gdt-bugs.patch Percpu and GDT fixes. x86-map-enough-initial-memory.patch Fix head.S to map enough memory. cleanup-cleanup-asm-bugs_h.patch cleanup-identify_cpu-fix.patch This is the pair I tried to post yesterday, but they got interrupted by an network outage. They basically add a little more cleanup, and move a misplaced hunk. cleanup-cleanup-asm-bugs_h.patch should go after/roll into the clean-up-asm-(i386|x86_64)-bugs_h patches, and cleanup-iden...

...0 }; @@ -423,7 +422,7 @@ find_smp_config(void) VOYAGER_SUS_IN_CONTROL_PORT); current_thread_info()->cpu = boot_cpu_id; - write_pda(cpu_number, boot_cpu_id); + x86_write_percpu(cpu_number, boot_cpu_id); } /* @@ -436,7 +435,7 @@ smp_store_cpu_info(int id) *c = boot_cpu_data; - identify_cpu(c); + identify_secondary_cpu(c); } /* set up the trampoline and return the physical address of the code */ @@ -460,7 +459,7 @@ start_secondary(void *unused) /* external functions not defined in the headers */ extern void calibrate_delay(void); - secondary_cpu_init(); + cpu_init(); /*...

...0 }; @@ -423,7 +422,7 @@ find_smp_config(void) VOYAGER_SUS_IN_CONTROL_PORT); current_thread_info()->cpu = boot_cpu_id; - write_pda(cpu_number, boot_cpu_id); + x86_write_percpu(cpu_number, boot_cpu_id); } /* @@ -436,7 +435,7 @@ smp_store_cpu_info(int id) *c = boot_cpu_data; - identify_cpu(c); + identify_secondary_cpu(c); } /* set up the trampoline and return the physical address of the code */ @@ -460,7 +459,7 @@ start_secondary(void *unused) /* external functions not defined in the headers */ extern void calibrate_delay(void); - secondary_cpu_init(); + cpu_init(); /*...

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.

Hello! I'm having problems getting PCI pass-through to work. This is on a AMD64 system, paravirtualized with xen-hypervisor-4.0-amd64 4.0.0-1~experimental.1, dom0: linux-image-2.6.32-5-xen-amd64 2.6.32-12. From IRC, earlier today: <tschwinge> waldi: Aren't the Debian xen domU-capable kernels supposed to contain the PCI frontend (needed for PCI pass-through)? I'm getting: