similar to: [PATCH] x86 linux ioremap adjustment

While not wrong, avoiding the unnecessary output allows the compiler a little more freedom. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-06-12/xen/arch/x86/mm.c =================================================================== --- 2008-06-12.orig/xen/arch/x86/mm.c 2008-06-12 09:08:36.000000000 +0200 +++ 2008-06-12/xen/arch/x86/mm.c 2008-06-12 09:08:42.000000000 +0200 @@

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

Fold compiler generated sections (mostly due to -fPIC on x86-64) into the general .data and .data.read_mostly sections. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2010-12-23.orig/xen/arch/x86/xen.lds.S +++ 2010-12-23/xen/arch/x86/xen.lds.S @@ -51,12 +51,16 @@ SECTIONS __stop___pre_ex_table = .; *(.data.read_mostly) + *(.data.rel.ro) +

Make sure MFN read from pte is valid before accessing the page info structure associated with it. Drop guest-to-machine-physical translation from ptwr code. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-05-14/xen/arch/x86/mm.c =================================================================== --- 2007-05-14.orig/xen/arch/x86/mm.c 2007-05-14 13:43:50.000000000 +0200 +++

We should always install xen.efi into /usr/lib64/efi/; installation into /boot/efi/efi/$(EFI_VENDOR) remains dependent upon specifying EFI_VENDOR. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/xen/Makefile +++ b/xen/Makefile @@ -35,11 +35,16 @@ _install: $(TARGET).gz ln -f -s $(notdir $(TARGET))-$(XEN_FULLVERSION).gz $(DESTDIR)/boot/$(notdir $(TARGET))-$(XEN_VERSION).gz ln -f

While shuffling quite a few things around, this gets us closer to native, which clearly had a reason to do the DMI scan early. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-08/arch/i386/mm/ioremap-xen.c =================================================================== --- head-2007-02-08.orig/arch/i386/mm/ioremap-xen.c 2007-02-08 17:07:13.000000000 +0100 +++

clear_IO_APIC_pin() ignores entries that are set to delivery mode SMI. While this seems reasonable if the entry was unmasked, I consider it dubious for masked entries. In Linux, such behavior is benign since when the entry later is being used for some normal interrupt, the old setting is simply overwritten. In Xen, however, ioapic_guest_write() uses the vector field to determine the previous

.. is out of sync on i386 and x86-64 - should it be allowed on i386, or should it be suppressed on x86-64? Since Xen fails ill accesses, I would assume enabling it on i386 is fine. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

is_local_lowmem() treats its physical address input as a machine address; this causes agpgart to fail while calling ioremap_nocache(). X still does not load on my Athlon 64 / Via S3 Unichrome, so perhaps best not to apply just yet. Signed-off-by: Avi Kivity <avi@qumranet.com> --- xen-ioremap-fix/linux-2.6-xen-sparse/arch/i386/mm/ioremap-xen.c~ioremap 2006-06-22 20:30:20.000000000 +0300

Fixes made in version 2: 1) Use PML4[257] for ioremap of PCI mmcfg. As full 16-bit segment support would require 44-bits. Since each slot only has 39-bits, we support 2048 PCI segments for now. This can be easily expanded if deemed necessary in the future. 2) Integrated PCI mmcfg access with existing PCI config interface for x86_64. Use MMCFG interface if offset is greater than 256.

Short of getting an explanation for the odd difference to native, make the code match native (and also, in the case of x86-64, __smp_call_function_single()). As usual, written and tested against 2.6.24-rc3 and made apply against 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-11-30/arch/i386/kernel/smp-xen.c

As usual, written and tested on 2.6.25.2 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-05-08/arch/x86_64/mm/pageattr-xen.c =================================================================== --- head-2008-05-08.orig/arch/x86_64/mm/pageattr-xen.c 2008-05-15 13:44:37.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

Similar to the local APIC changes, the IO-APIC access mechanisms should also be restricted to the Xen-specific ones (other than for the local APIC, where the access mechanisms must be entirely suppressed). A nice side effect of this is that the fixmap area shrinks quite a bit, allowing 32-bits to use a little more low memory. Signed-off-by: Jan Beulich <jbeulich@novell.com>

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

Use halt() instead (respective mainline patch will be submitted soon). Signed-off-by: Jan Beulich <jbeulich@novell.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Cannot use virt_to_machine() on a kmap()-ed address. As usual, written and tested on 2.6.24 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-01-28/arch/i386/mm/hypervisor.c =================================================================== --- head-2008-01-28.orig/arch/i386/mm/hypervisor.c 2007-10-19

Hello , I have installed RHEL 5 on a Intel Core Duo processor based board. It has 1 GB of physical memory. I have a driver which uses the memory reserved at the top of the high memory. Well this driver worked fine on all the previous versions of RHEL/FC and also with RHEL 5 with virtualization disabled. But with virtualization enabled , the ioremap to the memory reserved at the top of high

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