Gerd Hoffmann <[email protected]> writes:
>> Currently my assumptions are:
>>
>> Standalone executables load at the physical not the virtual addresses.
>> Standalone executables start executing at a physical address and not at
>> a virtual address.
>
> Well, that is true for real hardware. xen guest kernels are booted with
> paging already enabled and thus the entry point is in virtual memory,
> and I'm trying to figure how to handle that best (both for initial boot
> and kexec).
>
> xen uses a special xen header anyway to give the domain builder a hint
> how the initial page tables should look like (they look simliar to what
> head.S creates on real hardware). That can also be used to figure the
> correct virtual entry point from the physical one. It probably even
> makes more sense to do that (instead of writing the virtual address into
> the entry point) as the xen domain builder doesn't look at the virtual
> addresses in the ELF headers too. It uses PAGE_OFFSET+paddr instead.
> That keeps the differences between real and virtual hardware small ...
Ok. The unmerged Xen case.
I have some pending patches that make a bzImage a ET_DYN executable.
Would that be interesting to you? Especially if that would just mean
your initial page tables got to set physical == virtual?
I believe Xen does expose the actual physical addresses to the guest.
Either that or this is a case where Xen probably needs to take a
different path in the build system.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
