similar to: [PATCH 0/1] fix xen-crash at panic()-call during boot

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 that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

Guests other than domain 0 using the console output have previously been controlled by the VERBOSE #define, but with no designation of which guest''s output was on the console. This patch converts the HVM output buffering to be used by all domains except the hardware domain (dom0): stripping non-printable characters, line buffering the output, and prefixing it with the domain ID. This is

Guests other than domain 0 using the console output have previously been controlled by the VERBOSE define, but with no designation of which guest''s output was on the console. This patch converts the HVM output buffering to be used by all domains, line buffering their output and prefixing it with the domain ID. This is especially useful for debugging stub domains. Signed-off-by: Daniel De

Hi Wei, A Debian user has hit this message and reported it in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684661 I think it is the BUG_ON in: struct amd_iommu *find_iommu_for_device(int bdf) { BUG_ON ( bdf >= ivrs_bdf_entries ); return ivrs_mappings[bdf].iommu; } It looks like ivrs_bdf_entries comes from ACPI. Unfortunately the bug report

Hi Wei, A Debian user has hit this message and reported it in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684661 I think it is the BUG_ON in: struct amd_iommu *find_iommu_for_device(int bdf) { BUG_ON ( bdf >= ivrs_bdf_entries ); return ivrs_mappings[bdf].iommu; } It looks like ivrs_bdf_entries comes from ACPI. Unfortunately the bug report

Hi! From other people posting to this list, I know that there has been a bug related to the issue described in Xen Security Advisory 36 that disables iommu for some AMD users like me. However, even when passing "iommu=no-amd-iommu-perdev-intremap" it still disables i/o virtualisatoin. Related Xen dmesg output: (XEN) IVHD Error: Invalid IO-APIC 0 (XEN) AMD-Vi: Error initialization

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>

$ cd $ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.tar.gz $ tar -xzf linux-2.6.38.tar.gz $ wget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.38-2.tar.bz2 $ mkdir xenpatch-2.6.38.2 $ cd xenpatch-2.6.38-2 $ tar -xjf ../xen-patches-2.6.38-2.tar.bz2 $ cd .. $ cd linux-2.6.38 $ for i in `ls ../xenpatch-2.6.38.2/`; do patch -p1 <

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 workaround is taken from Linux, and the main motivation (besides such workarounds indeed belonging in the hypervisor rather than each kernel) is to suppress the warnings in the Xen log each Linux guest would cause due to the disallowed wrmsr. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -43,6 +43,47 @@ static inline void

Import upstream git commit e9dff0ee6694b2edd40b1b448cb786f6a7b02336 [PATCH] i386: mark cpu cache functions as __cpuinit Mark i386-specific cpu cache functions as __cpuinit. They are all only called from arch/i386/common.c:display_cache_info() that already is marked as __cpuinit. Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Signed-off-by: Andi Kleen

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1358452024 18000 # Node ID 40881d58e991fb6bc6089e0dcea23059cf651892 # Parent b6195e277da52129d5d79f29ccac0e7290643e37 AMD: Enable WC+ memory type on family 10 processors In some cases BIOS may not enable WC+ memory type on family 10 processors, instead converting what would be WC+ memory to CD type. On guests

This patch set adds basic supports for amd next generation iommu (IOMMUv2) hardware. IOMMUv2 supports various new features advertised by iommu extended feature register. It introduces guest level IO translation and supports state-of-the-art ATS/ATC devices with demand paging capability. Please refer to AMD IOMMU Architectural Specification [1] for more details. Thanks, Wei [1]

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

When xl is called to create a domU and there is not enough memory available, then the autoballooning is called to extract memory from dom0. During the ballooning a loop in libxl_wait_for_free_memory() waits unless enough memory is available to create the domU. But because of a variable-underflow the loop can finish too soon and xl finally aborts with the message: xc: error: panic: