similar to: [PATCH] x86-64 linux: don''t use hlt instruction

Instead, propagate the condition to the caller, all of which also get adjusted to check for that situation. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2011-03-09.orig/xen/arch/x86/mm.c +++ 2011-03-09/xen/arch/x86/mm.c @@ -5141,8 +5141,11 @@ int map_pages_to_xen( while ( nr_mfns != 0 ) { #ifdef __x86_64__ - l3_pgentry_t *pl3e = virt_to_xen_l3e(virt); -

Matching the comment in iommu_set_dom0_mapping(), map only actual RAM from the address range starting at 4G. It''s not clear though whether that comment is actually correct (which is why I''m sending this as RFC), but it is certain that on systems with sparse physical memory map we''re currently wasting a potentially significant amount of memory for setting up IOMMU page

flight 6714 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/6714/ Regressions :-( Tests which did not succeed and are blocking: build-amd64-oldkern 4 xen-build fail REGR. vs. 6658 build-amd64 4 xen-build fail REGR. vs. 6658 build-i386-oldkern 4 xen-build fail REGR. vs. 6658

flight 6412 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/6412/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-xcpkern-i386-xl-credit2 11 guest-localmigrate fail REGR. vs. 6379 Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-win 16

flight 9061 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/9061/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 8995 Tests which are failing intermittently (not blocking): test-amd64-i386-pv 5 xen-boot fail pass in 9054 test-i386-i386-pv

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

We really don''t want the mmconf window to move/disappear whenever we use is ourselves, not only when we enabled it. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -2297,8 +2297,7 @@ static int emulate_privileged_op(struct goto fail; if ( #ifdef CONFIG_X86_64 - (pci_probe

Make sure the upper 32 bits of RAX are disregarded during MSR write emulation. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-08-08/xen/arch/x86/traps.c =================================================================== --- 2007-08-08.orig/xen/arch/x86/traps.c 2007-08-08 11:37:08.000000000 +0200 +++ 2007-08-08/xen/arch/x86/traps.c 2007-08-08 11:40:02.000000000 +0200 @@

Appearantly a merge oversight that pre-dates 2.6.16. As usual, written and tested on 2.6.25-rc3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/include/asm-x86_64/mach-xen/asm/processor.h +++ b/include/asm-x86_64/mach-xen/asm/processor.h @@ -167,12 +167,6 @@ } -/* - * Bus types - */ -#define MCA_bus 0 -#define

As usual, written and tested on 2.6.27.3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- head-2008-10-24.orig/arch/x86_64/kernel/entry-xen.S 2008-10-24 11:32:19.000000000 +0200 +++ head-2008-10-24/arch/x86_64/kernel/entry-xen.S 2008-10-24 11:33:13.000000000 +0200 @@ -121,9 +121,9 @@ NMI_MASK = 0x80000000 .macro

That change converted the (wrong) assumption of contiguous nodes'' memory to a similarly wrong one of assuming discontiguous memory (i.e. each node having separate E820 table entries). The code ought to be able to deal with both, though, and I hope this change makes it so. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2009-08-24.orig/xen/arch/x86/srat.c 2009-08-28

Otherwise, pause or the recommended one-byte ret workaround on AMD processors may have ill side effects. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-02-07/xen/arch/x86/x86_emulate.c =================================================================== --- 2007-02-07.orig/xen/arch/x86/x86_emulate.c 2007-02-08 08:46:39.000000000 +0100 +++ 2007-02-07/xen/arch/x86/x86_emulate.c

flight 8111 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8111/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-amd 12 guest-localmigrate/x10 fail in 8104 REGR. vs. 8020 Tests which are failing intermittently (not blocking): test-amd64-i386-rhel6hvm-amd 11 guest-localmigrate.2 fail pass in 8104

One could even debate whether reserved bit faults are always fatal (and should never be propagated to the guest)... Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-01-28/xen/arch/x86/traps.c =================================================================== --- 2008-01-28.orig/xen/arch/x86/traps.c 2008-01-28 11:31:44.000000000 +0100 +++ 2008-01-28/xen/arch/x86/traps.c

flight 8270 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8270/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 8256 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken test-amd64-amd64-win 3 host-install(3) broken test-amd64-i386-pv

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains.

On 18.02.20 22:03, Thomas Gleixner wrote: > Juergen Gross <jgross at suse.com> writes: >> Commit 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control >> ioperm() as well") reworked the iopl syscall to use I/O bitmaps. >> >> Unfortunately this broke Xen PV domains using that syscall as there >> is currently no I/O bitmap support in PV domains.

Forcibly enabling the MMCFG space on AMD Fam10 CPUs cannot be expected to work since with the firmware not 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

Hello, The email (thread) below from xen-devel mailinglist indicates the changesets that should fix the bug that causes the lenny 2.6.26 xen kernel to crash on newer xen hypervisors. The workaround for this bug has been to use pci=nomsi on the dom0 kernel cmdline, but it would be better to apply the actual fix to the xen kernel in lenny. More information on xen-devel (archives). -- Pasi

This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0, noticing that all this setup is pointless when ARAT support is there, and knowing that on SLED11''s native kernel it has actually caused S3 resume issues. A question would be whether HPET legacy interrupts should be forced off in this case (rather than leaving whatever came from firmware). Signed-off-by: Jan Beulich