similar to: [PATCH 04/11] x86: cleanup mpparse.c

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

Use their proper counterparts in include/acpi/actbl*.h instead. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/ia64/xen/dom_fw_common.c +++ b/xen/arch/ia64/xen/dom_fw_common.c @@ -347,7 +347,7 @@ struct fake_acpi_tables { struct acpi_table_header dsdt; uint8_t aml[8 + 11 * MAX_VIRT_CPUS]; struct acpi_table_madt madt; - struct acpi_table_lsapic lsapic[MAX_VIRT_CPUS]; +

Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI names. This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the range FIRST-LAST_HIPRIORITY_VECTORs are free once again. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100 +++

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

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

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

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

1: IOMMU: properly check whether interrupt remapping is enabled 2: AMD IOMMU: only disable when certain IVRS consistency checks fail 3: VT-d: deal with 5500/5520/X58 errata Patch 1 and 2 are version 2 of a previously submitted, then withdrawn patch following up after XSA-36. Patch 3 is version 3 of a patch previously sent by Malcolm and Andrew. Signed-off-by: Jan Beulich

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

Hi, Is there any documentation on enabling hypervisor support for both C and P-state control? On xen-unstable and linux-2.6.18-xen.hg, if I enable cpuidle=1 on the xen command line and then run xenpm, I will get output for C-states (shown below) but it complains that "Xen cpufreq is not enabled!" cpu id : 0 total C-states : 2 idle time(ms) : 73264 C0

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