| Message ID | 20240823193630.2583107-1-jason.andryuk@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/pvh: Make 64bit PVH entry relocatable | expand |
x86 maintainers, are you going to pick this series up, or should I take it via the Xen tree? Juergen On 23.08.24 21:36, Jason Andryuk wrote: > Using the PVH entry point, the uncompressed vmlinux is loaded at > LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the > address in XEN_ELFNOTE_PHYS32_ENTRY, pvh_start_xen, with paging > disabled. > > Loading at LOAD_PHYSICAL_ADDR has not been a problem in the past as > virtual machines don't have conflicting memory maps. But Xen now > supports a PVH dom0, which uses the host memory map, and there are > Coreboot/EDK2 firmwares that have reserved regions conflicting with > LOAD_PHYSICAL_ADDR. Xen recently added XEN_ELFNOTE_PHYS32_RELOC to > specify an alignment, minimum and maximum load address when > LOAD_PHYSICAL_ADDR cannot be used. This patch series makes the PVH > entry path PIC to support relocation. > > Only x86-64 is converted. The 32bit entry path calling into vmlinux, > which is not PIC, will not support relocation. > > The entry path needs pages tables to switch to 64bit mode. A new > pvh_init_top_pgt is added to make the transition into the startup_64 > when the regular init_top_pgt pagetables are setup. This duplication is > unfortunate, but it keeps the changes simpler. __startup_64() can't be > used to setup init_top_pgt for PVH entry because it is 64bit code - the > 32bit entry code doesn't have page tables to use. > > This is the straight forward implementation to make it work. Other > approaches could be pursued. > > checkpatch.pl gives an error: "ERROR: Macros with multiple statements > should be enclosed in a do - while loop" about the moved PMDS macro. > But PMDS is an assembler macro, so its not applicable. There are some > false positive warnings "WARNING: space prohibited between function name > and open parenthesis '('" about the macro, too. > > v2 addresses review feedback. It also replace LOAD_PHYSICAL_ADDR with > _pa(pvh_start_xen) in some offset calculations. They happened to be > equal in my original builds. When the two values differ, > _pa(pvh_start_xen) is the correct one to use. > > v3: Fix build error for 32bit. Add Juergen's R-b to patch 4. > > Jason Andryuk (5): > xen: sync elfnote.h from xen tree > x86/pvh: Make PVH entrypoint PIC for x86-64 > x86/pvh: Set phys_base when calling xen_prepare_pvh() > x86/kernel: Move page table macros to header > x86/pvh: Add 64bit relocation page tables > > arch/x86/include/asm/pgtable_64.h | 23 ++++- > arch/x86/kernel/head_64.S | 20 ---- > arch/x86/platform/pvh/head.S | 161 +++++++++++++++++++++++++++--- > include/xen/interface/elfnote.h | 93 ++++++++++++++++- > 4 files changed, 259 insertions(+), 38 deletions(-) > > > base-commit: 7c626ce4bae1ac14f60076d00eafe71af30450ba
On 16.09.24 10:44, Juergen Gross wrote: > x86 maintainers, > > are you going to pick this series up, or should I take it via the > Xen tree? I take the silence as a "its okay to go via the Xen tree". Juergen
On 9/25/24 02:28, Juergen Gross wrote: > On 16.09.24 10:44, Juergen Gross wrote: >> x86 maintainers, >> >> are you going to pick this series up, or should I take it via the >> Xen tree? > > I take the silence as a "its okay to go via the Xen tree". Or, "most of us were traveling last week and in a bigger email hole than normal". ;) But, yeah, feel free to take this via the Xen tree. I just acked the only one that's not quite Xen-specific.
Using the PVH entry point, the uncompressed vmlinux is loaded at LOAD_PHYSICAL_ADDR, and execution starts in 32bit mode at the address in XEN_ELFNOTE_PHYS32_ENTRY, pvh_start_xen, with paging disabled. Loading at LOAD_PHYSICAL_ADDR has not been a problem in the past as virtual machines don't have conflicting memory maps. But Xen now supports a PVH dom0, which uses the host memory map, and there are Coreboot/EDK2 firmwares that have reserved regions conflicting with LOAD_PHYSICAL_ADDR. Xen recently added XEN_ELFNOTE_PHYS32_RELOC to specify an alignment, minimum and maximum load address when LOAD_PHYSICAL_ADDR cannot be used. This patch series makes the PVH entry path PIC to support relocation. Only x86-64 is converted. The 32bit entry path calling into vmlinux, which is not PIC, will not support relocation. The entry path needs pages tables to switch to 64bit mode. A new pvh_init_top_pgt is added to make the transition into the startup_64 when the regular init_top_pgt pagetables are setup. This duplication is unfortunate, but it keeps the changes simpler. __startup_64() can't be used to setup init_top_pgt for PVH entry because it is 64bit code - the 32bit entry code doesn't have page tables to use. This is the straight forward implementation to make it work. Other approaches could be pursued. checkpatch.pl gives an error: "ERROR: Macros with multiple statements should be enclosed in a do - while loop" about the moved PMDS macro. But PMDS is an assembler macro, so its not applicable. There are some false positive warnings "WARNING: space prohibited between function name and open parenthesis '('" about the macro, too. v2 addresses review feedback. It also replace LOAD_PHYSICAL_ADDR with _pa(pvh_start_xen) in some offset calculations. They happened to be equal in my original builds. When the two values differ, _pa(pvh_start_xen) is the correct one to use. v3: Fix build error for 32bit. Add Juergen's R-b to patch 4. Jason Andryuk (5): xen: sync elfnote.h from xen tree x86/pvh: Make PVH entrypoint PIC for x86-64 x86/pvh: Set phys_base when calling xen_prepare_pvh() x86/kernel: Move page table macros to header x86/pvh: Add 64bit relocation page tables arch/x86/include/asm/pgtable_64.h | 23 ++++- arch/x86/kernel/head_64.S | 20 ---- arch/x86/platform/pvh/head.S | 161 +++++++++++++++++++++++++++--- include/xen/interface/elfnote.h | 93 ++++++++++++++++- 4 files changed, 259 insertions(+), 38 deletions(-) base-commit: 7c626ce4bae1ac14f60076d00eafe71af30450ba