similar to: [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs

The DMI checks that force the use of the bigsmp APIC driver are for systems that are no longer supported by Xen (32-bit x86). Signed-off-by: Matt Wilson <msw@amazon.com> Cc: Keir Fraser <keir@xen.org> Cc: Jan Beulich <jbeulich@suse.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> --- xen/arch/x86/genapic/bigsmp.c | 30 +----------------------------- 1 files changed, 1

x86:x2apic: Disable x2apic on x86-32 permanently x2apic initialization on x86_32 uses vcpu pointer before it is initialized. As x2apic is unlikely to be used on x86_32, this patch disables x2apic permanently on x86_32. It also asserts the sanity of vcpu pointer before dereference to prevent further misuse. Signed-off-by: Fengzhe Zhang <fengzhe.zhang@intel.com> diff -r 02c0af2bf280

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu code can be called before iommu_setup() is processed. If there is no iommu 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

Hi, I''ve still have problems with ACPI(?) on Xen. After some system startup or resume CPU temperature goes high although all domUs (and dom0) are idle. On "good" system startup it is about 50-55C, on "bad" - above 67C (most time above 70C). I''ve noticed difference in C-states repored by Xen (attached files). On "bad" startups in addition suspend

Remove unused and pointless bits from mpparse.c (and other files where they are related to it). Of what remains, move whatever possible into .init.*, and some data items into .data.read_mostly. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2011-03-09.orig/xen/arch/x86/acpi/boot.c +++ 2011-03-09/xen/arch/x86/acpi/boot.c @@ -177,7 +177,8 @@ acpi_parse_x2apic(struct acpi_subtable_h

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one intterupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one intterupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one intterupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Cc: Andrew Morton <akpm at

The following two patches allow the parallel use of memsharing, xenpaging and xen-access by using an independent ring buffer for each feature. Please review. v2: - update mem_event_check_ring arguments, check domain rather than domain_id - check ring_full first because its value was just evaluated - check if ring buffer is initialized before calling mem_access_domctl/mem_paging_domctl

Currently the vector is not freed for MSI interrupt, the three patches fix the issue. The first patch(pirq.patch) move the get_free_pirq/map(unmap)_domain_pirq from arch/x86/physdev.c to arch/x86/irq.c, since that should be part of irq managment, no logic changes. The second patch(msi_vector_clean.patch) free the vector when the pirq is unmapped or when domain destroy. One thing need notice for

This patch enables x86-64 Xen dom0 to compile if IOMMU is enabled in the kernel config. Warning, dom0 will crash during boot of the kernel if IOMMU is enabled. These changes do not affect non-IOMMU enabled kernels (a fact I have verified myself). I am currently working on debugging the IOMMU dom0 crash. Signed-off-by: Jon Mason <jdmason@us.ibm.com> ---

Hello When i try to make world (any) from xen-3.0.2 to xen-unstable-src I gat following error : gcc -O2 -fomit-frame-pointer -DNDEBUG -m64 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/test1/xen-unstable/xen/include