Change LOAD_OFFSET so that the kernel has virtual addresses in the elf header fields.
Unlike bare metal kernels, Xen kernels start with virtual address
management turned on and thus the addresses to load to should be
virtual addresses.
Signed-off-by: Ian Pratt <[email protected]>
Signed-off-by: Christian Limpach <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
---
arch/i386/kernel/vmlinux.lds.S | 2 +-
include/asm-i386/mach-default/mach_vmlinux.lds.h | 6 ++++++
include/asm-i386/mach-xen/mach_vmlinux.lds.h | 6 ++++++
3 files changed, 13 insertions(+), 1 deletion(-)
--- linus-2.6.orig/arch/i386/kernel/vmlinux.lds.S
+++ linus-2.6/arch/i386/kernel/vmlinux.lds.S
@@ -2,7 +2,7 @@
* Written by Martin Mares <[email protected]>;
*/
-#define LOAD_OFFSET __PAGE_OFFSET
+#include "mach_vmlinux.lds.h"
#include <asm-generic/vmlinux.lds.h>
#include <asm/thread_info.h>
--- /dev/null
+++ linus-2.6/include/asm-i386/mach-default/mach_vmlinux.lds.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_MACH_VMLINUX_LDS_H
+#define __ASM_MACH_VMLINUX_LDS_H
+
+#define LOAD_OFFSET __PAGE_OFFSET
+
+#endif /* __ASM_MACH_VMLINUX_LDS_H */
--- /dev/null
+++ linus-2.6/include/asm-i386/mach-xen/mach_vmlinux.lds.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_MACH_VMLINUX_LDS_H
+#define __ASM_MACH_VMLINUX_LDS_H
+
+#define LOAD_OFFSET 0
+
+#endif /* __ASM_MACH_VMLINUX_LDS_H */
--
Chris Wright wrote:
> Change LOAD_OFFSET so that the kernel has virtual addresses in the elf header fields.
>
> Unlike bare metal kernels, Xen kernels start with virtual address
> management turned on and thus the addresses to load to should be
> virtual addresses.
This patch interferes with using a traditional bootloader. The loader
for Xen should be smarter - it already has VIRT_BASE from the xen_guest
section, and can simply add the relocation to these header fields. This
is unnecessary, and one of the many reasons a Xen kernel can't run in a
normal environment.
Zach
Zachary Amsden wrote:
> Chris Wright wrote:
>> Change LOAD_OFFSET so that the kernel has virtual addresses in the elf
>> header fields.
>>
>> Unlike bare metal kernels, Xen kernels start with virtual address
>> management turned on and thus the addresses to load to should be
>> virtual addresses.
>
> This patch interferes with using a traditional bootloader. The loader
> for Xen should be smarter - it already has VIRT_BASE from the xen_guest
> section, and can simply add the relocation to these header fields. This
> is unnecessary, and one of the many reasons a Xen kernel can't run in a
> normal environment.
I fully agree. Attached below is a patch (against xen unstable
mercurial tree) which does exactly that ;)
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
Erst mal heiraten, ein, zwei Kinder, und wenn alles l?uft
geh' ich nach drei Jahren mit der Familie an die B?rse.
http://www.suse.de/~kraxel/julika-dora.jpeg
* Gerd Hoffmann ([email protected]) wrote:
> I fully agree. Attached below is a patch (against xen unstable
> mercurial tree) which does exactly that ;)
Thanks Gerd, I thought you had been working on that. Was the concern
with vaddr vs. paddr worked out?
thanks,
-chris
Chris Wright wrote:
> * Gerd Hoffmann ([email protected]) wrote:
>> I fully agree. Attached below is a patch (against xen unstable
>> mercurial tree) which does exactly that ;)
>
> Thanks Gerd, I thought you had been working on that. Was the concern
> with vaddr vs. paddr worked out?
Not yet, and I didn't feel comfortable pushing it just before the 3.0.2
release, but I think _now_ would be a good time to finally merge it.
Having physical addresses in paddr seems to be common practice, and IMO
xen should follow that as it makes life easier for everybody.
It's not a big problem that xen guests boot with paging enabled, and as
Zachary already pointed out it's trivial to use virt_base from the
xen_guest elf section to create correct initial page tables.
Even maintaining backward compatibility with some guesswork is possible
as it is _very_ unlikely that the paddr field holds physical addresses
larger than virt_base ;)
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
Erst mal heiraten, ein, zwei Kinder, und wenn alles l?uft
geh' ich nach drei Jahren mit der Familie an die B?rse.
http://www.suse.de/~kraxel/julika-dora.jpeg
On Wed, May 10, 2006 at 04:28:51PM -0700, Zachary Amsden wrote:
> Chris Wright wrote:
> >Change LOAD_OFFSET so that the kernel has virtual addresses in the elf
> >header fields.
> >
> >Unlike bare metal kernels, Xen kernels start with virtual address
> >management turned on and thus the addresses to load to should be
> >virtual addresses.
>
> This patch interferes with using a traditional bootloader. The loader
> for Xen should be smarter - it already has VIRT_BASE from the xen_guest
> section, and can simply add the relocation to these header fields. This
> is unnecessary, and one of the many reasons a Xen kernel can't run in a
> normal environment.
It's certainly not as simple as you make it sound, if you want to
support existing kernels without having to guess how the kernel image
was built.
I've updated our loader to support this now, so that this patch is
no longer necessary. I have at the same time added a new field to
xen_guest which allows specifying the entry point, allowing us to have
a different entry point when running the kernel image on Xen.
christian
>I've updated our loader to support this now, so that this patch is
>no longer necessary. I have at the same time added a new field to
>xen_guest which allows specifying the entry point, allowing us to have
>a different entry point when running the kernel image on Xen.
Why do you need a separate entry point here? The code should be able to figure out which mode it is run in without
problems...
Jan
On Fri, May 12, 2006 at 08:47:13AM +0200, Jan Beulich wrote:
> >I've updated our loader to support this now, so that this patch is
> >no longer necessary. I have at the same time added a new field to
> >xen_guest which allows specifying the entry point, allowing us to have
> >a different entry point when running the kernel image on Xen.
>
> Why do you need a separate entry point here? The code should be able to figure out which mode it is run in without
> problems...
I think it's the cleanest way to have different startup code for
native and non-native in the same kernel. But even if that's not
needed (for Linux), then you can have it point at the same address.
It is also always pointing to a virtual address, while the elf header
one now points to a physical address which doesn't make much sense
in the environment we start the kernel.
christian
