amd64/xen: move early PVH entry point code from assembly to C

[royger]

Summary

Attempt to reduce the assembly code used by the Xen PVH entry point, by moving
the page table creation and GDT definitions to C. Such code needs to be built
in 32 bit mode, and linked specially so that VMA == LMA, because the code is
run in 32 bit protected mode (no page-tables).

This is in preparation for adding support for the FreeBSD binary being
relocatable when loaded from Xen, at which point bootstrap page table creation
would be more complicated, and hence better done in C.

The current code however cannot be committed, because Elftoolchain objcopy
segfaults when dong the conversion from elf32-i386 -> elf64-x86-64. LLVM
objcopy however works fine, hence this is blocked until LLVM objcopy has
replaced elftoolchain objcopy in base.

Sponsored by: Cloud Software Group

[markj]

The current code however cannot be committed, because Elftoolchain objcopy segfaults when dong the conversion from elf32-i386 -> elf64-x86-64.

Is anyone actively working on switching? Maybe the objcopy bug is easy to fix.

sys/amd64/amd64/xen-start.c

1

This header should contain a copyright line as well.

2

cdefs.h shouldn't be needed here, you can assume that param.h includes it.

70

91

sys/conf/files.amd64

81

Should this file perhaps be called xen-start32.c or so?

sys/conf/ldscript.amd64

7

[markj]

I don't see a segfault when testing this patch, but objcopy fails while trying to update relocations. I guess it's somehow not handling the ELF class conversion. Anyway, it might not be too hard to fix, but the solution isn't obvious to me.

[royger]

In D44451#1016401, @markj wrote:

The current code however cannot be committed, because Elftoolchain objcopy segfaults when dong the conversion from elf32-i386 -> elf64-x86-64.

Is anyone actively working on switching? Maybe the objcopy bug is easy to fix.

I was under the impression that we intended to switch to llvm-objcopy at some point, but I cannot find any information now. I might have been confused with the llvm-objdump introduction. I will take a look at fixing elftoolchain objcopy.

[royger]

sys/amd64/amd64/xen-start.c

2

I think I introduced param.h after having adding cdefs.h, and so didn't realize it wasn't needed.

sys/conf/files.amd64

81

Sure.

[dim]

In D44451#1017071, @royger wrote:

In D44451#1016401, @markj wrote:

The current code however cannot be committed, because Elftoolchain objcopy segfaults when dong the conversion from elf32-i386 -> elf64-x86-64.

Is anyone actively working on switching? Maybe the objcopy bug is easy to fix.

I was under the impression that we intended to switch to llvm-objcopy at some point, but I cannot find any information now. I might have been confused with the llvm-objdump introduction. I will take a look at fixing elftoolchain objcopy.

There's an exp-run bug here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258872 which sets WITH_LLVM_BINUTILS. This also enables llvm-objcopy as objcopy.

The default has not been flipped yet because there was still some ports fallout which needs to be solved.