Page MenuHomeFreeBSD

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

Authored by royger on Mar 21 2024, 11:20 AM.
Tags
None
Referenced Files
F86279638: D44451.diff
Tue, Jun 18, 2:03 AM
Unknown Object (File)
Tue, Jun 11, 11:43 AM
Unknown Object (File)
Tue, Jun 11, 11:25 AM
Unknown Object (File)
Mon, Jun 10, 5:47 AM
Unknown Object (File)
Sun, Jun 2, 10:47 PM
Unknown Object (File)
Wed, May 29, 5:15 PM
Unknown Object (File)
May 13 2024, 4:30 AM
Unknown Object (File)
May 11 2024, 5:50 PM
Subscribers

Details

Reviewers
markj
emaste
dim
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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

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

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.

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.

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.

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.