[Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v12 - suggestions/fixes: - rename __efi64_start to __efi64_mb2_start (suggested by Andrew Cooper), - use efi_arch_memory_setup() machinery as trampoline et consortes main memory allocator (suggested by Doug Goldstein), - allocate space for mbi struct in efi_arch_memory_setup() too; this thing was not taken into account in earlier releases, - revert trampoline et consortes fallback memory allocator code in efi_arch_process_memory_map() to current upstream state (suggested by Doug Goldstein), - further simplify efi_arch_pre_exit_boot() code, - call efi_arch_memory_setup() from efi_multiboot2() (suggested by Doug Goldstein), - fix asembly call argument in xen/arch/x86/efi/stub.c (suggested by Andrew Cooper), - add ASSERT() for trampoline size (suggested by Doug Goldstein), - add KB() macro (suggested by Doug Goldstein), - improve comments (suggested by Andrew Cooper and Doug Goldstein). v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to increase code readability (suggested by Andrew Cooper). v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan Beulich). v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss) because latter is not tested extensively in different built environments yet (suggested by Andrew Cooper), - fix multiboot2 data scanning loop in x86_32 code (suggested by Jan Beulich), - add check for extra mem for mbi data if Xen is loaded via multiboot2 protocol on EFI platform (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v7 - suggestions/fixes: - do not allocate twice memory for trampoline if we were loaded via multiboot2 protocol on EFI platform, - wrap long line (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - improve label names in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - remove redundant BSS alignment, - update BSS alignment check, - use __set_bit() instead of set_bit() if possible (suggested by Jan Beulich), - call efi_arch_cpu() from efi_multiboot2() even if the same work is done later in other place right now (suggested by Jan Beulich), - xen/arch/x86/efi/stub.c:efi_multiboot2() fail properly on EFI platforms, - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - use 32-bit registers in x86_64 code if possible (suggested by Jan Beulich), - multiboot2 information address is 64-bit in x86_64 code, so, treat it is as is (suggested by Jan Beulich), - use cmovcc if possible, - leave only one space between rep and stosq (suggested by Jan Beulich), - improve error handling, - improve early error messages, (suggested by Jan Beulich), - improve early error messages printing code, - improve label names (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups. v3 - suggestions/fixes: - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - improve segment registers initialization (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Beulich). v2 - suggestions/fixes: - generate multiboot2 header using macros (suggested by Jan Beulich), - switch CPU to x86_32 mode before jumping to 32-bit code (suggested by Andrew Cooper), - reduce code changes to increase patch readability (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform and find on my own multiboot2.mem_lower value, - stop execution if EFI platform is detected in legacy BIOS path. --- xen/arch/x86/boot/head.S | 268 ++--- xen/arch/x86/efi/efi-boot.h | 61 - xen/arch/x86/efi/stub.c | 38 ++ xen/arch/x86/x86_64/asm-offsets.c |2 + xen/arch/x86/xen.lds.S|7 +- xen/common/efi/boot.c | 11 ++ xen/include/asm-x86/config.h |5 + xen/include/xen/config.h |1 + 8 files changed, 366 insertions(+), 27 deletions(-)
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On 1/19/17 8:34 PM, Daniel Kiper wrote: > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index 84cf44d..b8f727a 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > -2: /* Reserve 64kb for the trampoline */ > -sub $0x1000,%ecx > +/* Reserve memory for the trampoline. */ /* Reserve memory for the trampoline and the low memory stack */ > +sub $((MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE)>>4),%ecx > > /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */ > xor %cl, %cl > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 62c010e..c1285ad 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > @@ -550,7 +551,12 @@ static void __init efi_arch_memory_setup(void) > > /* Allocate space for trampoline (in first Mb). */ > cfg.addr = 0x10; > -cfg.size = trampoline_end - trampoline_start; > + > +if ( efi_enabled(EFI_LOADER) ) > +cfg.size = trampoline_end - trampoline_start; > +else > +cfg.size = MB_TRAMPOLINE_SIZE + MB_TRAMPOLINE_STACK_SIZE + MBI_SIZE; Why MBI_SIZE? I don't see that being copied in that region or living there? -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
>>> On 20.01.17 at 02:34, wrote:
> @@ -100,20 +107,48 @@ multiboot2_header_start:
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> +.long 0 /* Needed for 64-bit lgdt */
> +
> +.align 4
> +vga_text_buffer:
> +.long 0xb8000
> +
> +efi_platform:
> +.byte 0
You mean to modify these fields, but you add them to a r/o section.
> +.Lefi_multiboot2_proto:
> +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> +xor %esi,%esi
> +xor %edi,%edi
> +
> +/* Skip Multiboot2 information fixed part. */
> +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
In an earlier reply to Andrew's inquiry regarding the possible
truncation here you said that grub can be made obey to such a
load restriction. None of the tags added here or in patch 2
appear to have such an effect, so would you please clarify how
the address restriction is being enforced?
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +
> +.Lefi_mb2_tsize:
> +/* Check Multiboot2 information total size. */
> +mov %ecx,%r8d
> +sub %ebx,%r8d
> +cmp %r8d,MB2_fixed_total_size(%rbx)
> +jbe run_bs
> +
> +/* Are EFI boot services available? */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI_BS,MB2_tag_type(%rcx)
> +jne .Lefi_mb2_st
> +
> +/* We are on EFI platform and EFI boot services are available. */
> +incbefi_platform(%rip)
> +
> +/*
> + * Disable real mode and other legacy stuff which should not
> + * be run on EFI platforms.
> + */
> +incbskip_realmode(%rip)
> +jmp .Lefi_mb2_next_tag
> +
> +.Lefi_mb2_st:
> +/* Get EFI SystemTable address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
> +cmove MB2_efi64_st(%rcx),%rsi
> +je .Lefi_mb2_next_tag
> +
> +/* Get EFI ImageHandle address from Multiboot2 information. */
> +cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
> +cmove MB2_efi64_ih(%rcx),%rdi
> +je .Lefi_mb2_next_tag
> +
> +/* Is it the end of Multiboot2 information? */
> +cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> +je run_bs
> +
> +.Lefi_mb2_next_tag:
> +/* Go to next Multiboot2 information tag. */
> +add MB2_tag_size(%rcx),%ecx
> +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> +jmp .Lefi_mb2_tsize
> +
> +run_bs:
.Lrun_bs:
> +/* Are EFI boot services available? */
> +cmpb$0,efi_platform(%rip)
> +jnz 0f
> +
> +/* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> +lea .Lmb2_no_bs(%rip),%edi
> +jmp x86_32_switch
> +0:
I realize you need to avoid clobbering %rdi in the non-error case,
but the register choice seems sub-optimal: If you used a register
which you can clobber here (e.g. %edx as it seems, using %edi in
its place at x86_32_switch and cs32_switch), you could simplify
this to
cmpb ...
lea ...
je x86_32_switch
at once avoiding all the numeric labels here.
> +2:
> +push%rax
> +push%rdi
> +
> +/*
> + * Initialize BSS (no nasty surprises!).
> + * It must be done earlier than in BIOS case
> + * because efi_multiboot2() touches it.
> + */
> +lea __bss_start(%rip),%edi
> +lea __bss_end(%rip),%ecx
> +sub %edi,%ecx
> +shr $3,%ecx
> +xor %eax,%eax
> +rep stosq
> +
> +pop %rdi
> +
> +/*
> + * efi_multiboot2() is called according to System V AMD64 ABI:
> + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> + * - OUT: %rax - highest allocated memory address below 1 MiB;
> + * memory below this address is used for trampoline
> + * stack, trampoline itself and as a storage for
> + * mbi struct created in reloc().
> + *
> + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> + * on EFI platforms. Hence, it could not be used like
> + * on legacy BIOS platforms.
> + */
> +callefi_multiboot2
Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
further spec requirements for runtime calls") I'm worried about stack
alignment here. Does GrUB call or jmp to our entry point (and is that
firmly specified to be the case)? Perhaps it would be a good idea to
align the stack earlier on in any case. Or if not (and if alignment at
this call is ABI conforming), a comment should be left here to warn
people of future modifications to the amount of items pushed onto /
popped off the stack.
> +trampoline_setup:
> +/* Save trampoline addres
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 02:34, wrote:
> > @@ -100,20 +107,48 @@ multiboot2_header_start:
> > gdt_boot_descr:
> > .word 6*8-1
> > .long sym_phys(trampoline_gdt)
> > +.long 0 /* Needed for 64-bit lgdt */
> > +
> > +.align 4
> > +vga_text_buffer:
> > +.long 0xb8000
> > +
> > +efi_platform:
> > +.byte 0
>
> You mean to modify these fields, but you add them to a r/o section.
Yep. So, I think that we should move them to .init.data. Is it OK for you?
> > +.Lefi_multiboot2_proto:
> > +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> > +xor %esi,%esi
> > +xor %edi,%edi
> > +
> > +/* Skip Multiboot2 information fixed part. */
> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
>
> In an earlier reply to Andrew's inquiry regarding the possible
> truncation here you said that grub can be made obey to such a
> load restriction. None of the tags added here or in patch 2
> appear to have such an effect, so would you please clarify how
> the address restriction is being enforced?
GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
So, there is no need for extra tags.
Additionally, multiboot2 spec says this:
The bootloader must not load any part of the kernel, the modules, the Multiboot2
information structure, etc. higher than 4 GiB - 1. This requirement is put in
force because most of currently specified tags supports 32-bit addresses only.
Additionally, some kernels, even if they run on EFI 64-bit platform, still
execute some parts of its initialization code in 32-bit mode.
[...]
> > +.Lefi_mb2_next_tag:
> > +/* Go to next Multiboot2 information tag. */
> > +add MB2_tag_size(%rcx),%ecx
> > +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +jmp .Lefi_mb2_tsize
> > +
> > +run_bs:
>
> .Lrun_bs:
OK.
> > +/* Are EFI boot services available? */
> > +cmpb$0,efi_platform(%rip)
> > +jnz 0f
> > +
> > +/* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> > +lea .Lmb2_no_bs(%rip),%edi
> > +jmp x86_32_switch
> > +0:
>
> I realize you need to avoid clobbering %rdi in the non-error case,
> but the register choice seems sub-optimal: If you used a register
> which you can clobber here (e.g. %edx as it seems, using %edi in
> its place at x86_32_switch and cs32_switch), you could simplify
> this to
>
> cmpb ...
> lea ...
> je x86_32_switch
>
> at once avoiding all the numeric labels here.
If you do not care that it will be always loaded then OK. However, I think
that %r15d is a bit better here because if we need to add another argument
to efi_multiboot2() and we use %edx then we must change code in more places.
Of course we should do "mov %r15d,%edi" after x86_32_switch label then.
> > +2:
> > +push%rax
> > +push%rdi
> > +
> > +/*
> > + * Initialize BSS (no nasty surprises!).
> > + * It must be done earlier than in BIOS case
> > + * because efi_multiboot2() touches it.
> > + */
> > +lea __bss_start(%rip),%edi
> > +lea __bss_end(%rip),%ecx
> > +sub %edi,%ecx
> > +shr $3,%ecx
> > +xor %eax,%eax
> > +rep stosq
> > +
> > +pop %rdi
> > +
> > +/*
> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> > + * memory below this address is used for trampoline
> > + * stack, trampoline itself and as a storage for
> > + * mbi struct created in reloc().
> > + *
> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> > + * on EFI platforms. Hence, it could not be used like
> > + * on legacy BIOS platforms.
> > + */
> > +callefi_multiboot2
>
> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> further spec requirements for runtime calls") I'm worried about stack
> alignment here. Does GrUB call or jmp to our entry point (and is that
> firmly specified to be the case)? Perhaps it would be a good idea to
> align the stack earlier on in any case. Or if not (and if alignment at
> this call is ABI conforming), a comment should be left here to warn
> people of future modifications to the amount of items pushed onto /
> popped off the stack.
Multiboot2 spec requires that stack, among others, is passed to loaded
image according to UEFI spec. Though, IIRC, there are no extra stack checks
there. Maybe we should add something to GRUB2 if it does not exists.
> > +trampoline_setup:
> > +/* Save trampoline
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
>>> On 20.01.17 at 12:43, wrote:
> On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
>> >>> On 20.01.17 at 02:34, wrote:
>> > @@ -100,20 +107,48 @@ multiboot2_header_start:
>> > gdt_boot_descr:
>> > .word 6*8-1
>> > .long sym_phys(trampoline_gdt)
>> > +.long 0 /* Needed for 64-bit lgdt */
>> > +
>> > +.align 4
>> > +vga_text_buffer:
>> > +.long 0xb8000
>> > +
>> > +efi_platform:
>> > +.byte 0
>>
>> You mean to modify these fields, but you add them to a r/o section.
>
> Yep. So, I think that we should move them to .init.data. Is it OK for you?
That's what I'm asking for, yes.
>> > +.Lefi_multiboot2_proto:
>> > +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
>> > +xor %esi,%esi
>> > +xor %edi,%edi
>> > +
>> > +/* Skip Multiboot2 information fixed part. */
>> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
>>
>> In an earlier reply to Andrew's inquiry regarding the possible
>> truncation here you said that grub can be made obey to such a
>> load restriction. None of the tags added here or in patch 2
>> appear to have such an effect, so would you please clarify how
>> the address restriction is being enforced?
>
> GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
> So, there is no need for extra tags.
>
> Additionally, multiboot2 spec says this:
>
> The bootloader must not load any part of the kernel, the modules, the
> Multiboot2
> information structure, etc. higher than 4 GiB - 1. This requirement is put in
> force because most of currently specified tags supports 32-bit addresses only.
> Additionally, some kernels, even if they run on EFI 64-bit platform, still
> execute some parts of its initialization code in 32-bit mode.
Okay, that's good enough for now, even if it escapes me how that's
supposed to work on systems without any memory below 4Gb.
>> > +/* Are EFI boot services available? */
>> > +cmpb$0,efi_platform(%rip)
>> > +jnz 0f
>> > +
>> > +/* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
>> > +lea .Lmb2_no_bs(%rip),%edi
>> > +jmp x86_32_switch
>> > +0:
>>
>> I realize you need to avoid clobbering %rdi in the non-error case,
>> but the register choice seems sub-optimal: If you used a register
>> which you can clobber here (e.g. %edx as it seems, using %edi in
>> its place at x86_32_switch and cs32_switch), you could simplify
>> this to
>>
>> cmpb ...
>> lea ...
>> je x86_32_switch
>>
>> at once avoiding all the numeric labels here.
>
> If you do not care that it will be always loaded then OK.
That's okay, of course. The main thing is that we should prefer the
one branch variant over the two branches one.
> However, I think
> that %r15d is a bit better here because if we need to add another argument
> to efi_multiboot2() and we use %edx then we must change code in more places.
> Of course we should do "mov %r15d,%edi" after x86_32_switch label then.
As long as all affected code lives outside of the trampoline, using
any of the high 8 registers is certainly fine here.
>> > +2:
>> > +push%rax
>> > +push%rdi
>> > +
>> > +/*
>> > + * Initialize BSS (no nasty surprises!).
>> > + * It must be done earlier than in BIOS case
>> > + * because efi_multiboot2() touches it.
>> > + */
>> > +lea __bss_start(%rip),%edi
>> > +lea __bss_end(%rip),%ecx
>> > +sub %edi,%ecx
>> > +shr $3,%ecx
>> > +xor %eax,%eax
>> > +rep stosq
>> > +
>> > +pop %rdi
>> > +
>> > +/*
>> > + * efi_multiboot2() is called according to System V AMD64 ABI:
>> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
>> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
>> > + * memory below this address is used for
>> > trampoline
>> > + * stack, trampoline itself and as a storage for
>> > + * mbi struct created in reloc().
>> > + *
>> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
>> > + * on EFI platforms. Hence, it could not be used like
>> > + * on legacy BIOS platforms.
>> > + */
>> > +callefi_multiboot2
>>
>> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
>> further spec requirements for runtime calls") I'm worried about stack
>> alignment here. Does GrUB call or jmp to our entry point (and is that
>> firmly specified to be the case)? Perhaps it would be a good idea to
>> align the stack earlier on in any case. Or if not (and if alignment at
>> this call is ABI conforming), a comment should be left here to warn
>> people of future modifications to the amount of items pushed onto /
>> popped off the stack.
>
> Multiboot2 spec
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 12:43, wrote:
> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >> >>> On 20.01.17 at 02:34, wrote:
[...]
> >> > +.Lefi_multiboot2_proto:
> >> > +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> >> > +xor %esi,%esi
> >> > +xor %edi,%edi
> >> > +
> >> > +/* Skip Multiboot2 information fixed part. */
> >> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> >>
> >> In an earlier reply to Andrew's inquiry regarding the possible
> >> truncation here you said that grub can be made obey to such a
> >> load restriction. None of the tags added here or in patch 2
> >> appear to have such an effect, so would you please clarify how
> >> the address restriction is being enforced?
> >
> > GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
> > So, there is no need for extra tags.
> >
> > Additionally, multiboot2 spec says this:
> >
> > The bootloader must not load any part of the kernel, the modules, the
> > Multiboot2
> > information structure, etc. higher than 4 GiB - 1. This requirement is put
> > in
> > force because most of currently specified tags supports 32-bit addresses
> > only.
> > Additionally, some kernels, even if they run on EFI 64-bit platform, still
> > execute some parts of its initialization code in 32-bit mode.
>
> Okay, that's good enough for now, even if it escapes me how that's
> supposed to work on systems without any memory below 4Gb.
If you wish I can add relevant comment somewhere. Anyway, if there is no
mem below 4 GiB at least, IIRC, GRUB2 will fail during image load. So,
no worry. At least right now.
[...]
> >> > +/*
> >> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> >> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> >> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> >> > + * memory below this address is used for
> >> > trampoline
> >> > + * stack, trampoline itself and as a storage for
> >> > + * mbi struct created in reloc().
> >> > + *
> >> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> >> > + * on EFI platforms. Hence, it could not be used like
> >> > + * on legacy BIOS platforms.
> >> > + */
> >> > +callefi_multiboot2
> >>
> >> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> >> further spec requirements for runtime calls") I'm worried about stack
> >> alignment here. Does GrUB call or jmp to our entry point (and is that
> >> firmly specified to be the case)? Perhaps it would be a good idea to
> >> align the stack earlier on in any case. Or if not (and if alignment at
> >> this call is ABI conforming), a comment should be left here to warn
> >> people of future modifications to the amount of items pushed onto /
> >> popped off the stack.
> >
> > Multiboot2 spec requires that stack, among others, is passed to loaded
> > image according to UEFI spec. Though, IIRC, there are no extra stack checks
> > there. Maybe we should add something to GRUB2 if it does not exists.
>
> That would imply they do a call (and not a jmp), which would make
> the present code correct afaict. As said, imo there should still be a
> warning added here, for anyone wanting to modify the stack layout.
Will do.
[...]
> >> > --- a/xen/include/asm-x86/config.h
> >> > +++ b/xen/include/asm-x86/config.h
> >> > @@ -73,6 +73,11 @@
> >> > #define STACK_ORDER 3
> >> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
> >> >
> >> > +#define MB_TRAMPOLINE_STACK_SIZEPAGE_SIZE
> >> > +#define MB_TRAMPOLINE_SIZE (KB(64) -
> >> > MB_TRAMPOLINE_STACK_SIZE)
> >>
> >> What's the reason for the MB_ prefixes here? The trampoline is
> >> always the same size, isn't it? Nor am I convinced we really need
> >
> > Please take a look at efi_arch_memory_setup(). Amount of memory allocated
> > for trampoline and other stuff depends on boot loader type. So, when I use
> > "MB_" I would like underline that this is relevant for multiboot protocols.
> > Though I think that we can use the same size for all protocols. However,
> > I would not like to touch native EFI loader case.
>
> You already don't touch it, and I see no reason why this should
> change. Yet this is orthogonal to the naming of the constants here.
OK.
> As said, the trampoline itself is always the same, and the stack
Yep.
> portion of it is simply unused in the native EFI loader case. Plus
Hmmm... That is interesting why? I must take a look at trampoline code.
> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
> parts)?
So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
OK for you? And I can agree that this is bet
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
>>> On 20.01.17 at 14:46, wrote: > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote: >> >>> On 20.01.17 at 12:43, wrote: >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote: >> >> >>> On 20.01.17 at 02:34, wrote: >> >> > --- a/xen/include/asm-x86/config.h >> >> > +++ b/xen/include/asm-x86/config.h >> >> > @@ -73,6 +73,11 @@ >> >> > #define STACK_ORDER 3 >> >> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER) >> >> > >> >> > +#define MB_TRAMPOLINE_STACK_SIZEPAGE_SIZE >> >> > +#define MB_TRAMPOLINE_SIZE (KB(64) - >> >> > MB_TRAMPOLINE_STACK_SIZE) >> >> >> >> What's the reason for the MB_ prefixes here? The trampoline is >> >> always the same size, isn't it? Nor am I convinced we really need >> > >> > Please take a look at efi_arch_memory_setup(). Amount of memory allocated >> > for trampoline and other stuff depends on boot loader type. So, when I use >> > "MB_" I would like underline that this is relevant for multiboot protocols. >> > Though I think that we can use the same size for all protocols. However, >> > I would not like to touch native EFI loader case. >> >> You already don't touch it, and I see no reason why this should >> change. Yet this is orthogonal to the naming of the constants here. > > OK. > >> As said, the trampoline itself is always the same, and the stack > > Yep. > >> portion of it is simply unused in the native EFI loader case. Plus > > Hmmm... That is interesting why? I must take a look at trampoline code. It's a boot time only thing, and the boot path if different for native EFI. >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both >> parts)? > > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is > OK for you? And I can agree that this is better naming. Again, I don't see why you would need TRAMPOLINE_STACK_SPACE. >> >> two defines - except in the link time assertion you always use >> >> the sum of the two. >> >> >> >> > +#define MBI_SIZE(2 * PAGE_SIZE) >> >> >> >> On top of Doug's question - if it is needed at all, what does this >> > >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly >> > realize that there is following memory layout from top to bottom: >> > >> > +--+ >> > | TRAMPOLINE_STACK | >> > +--+ >> > |TRAMPOLINE| >> > +--+ >> > |mbi struct| >> > +--+ >> > >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)? >> > >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments, >> > memory map and other minor things. >> >> Even with a couple of dozen modules passed? But the primary > > Why not? The biggest thing is memory map. The rest are mostly > command line strings and a few pointers. Modules itself live > in different memory regions. Command line string may get lengthy. >> question was left unanswered anyway: Does this need placing in >> the low megabyte at all? And even if it does, especially if you > > I do not think so. I do not expect that anything in trampoline code > touches it. So, we can put it anywhere below 4 GiB. However, then > we need an allocator to properly allocate mbi struct region. And > at this boot stage this is not an easy thing. Depending for how long you need that data to stay around, there may be places to put it without much risk of overflowing anything. >> limit it to 8k, I don't see why it wouldn't fit inside the 64k >> trampoline area. > > If you wish why not. Though I think that we should use set of constants > here to avoid currently existing plain numbers mess in assembly. And > I have a feeling that this cleanup/fix should land into separate patch. Constants - sure. Separate patch - fine with me. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 07:10:32AM -0700, Jan Beulich wrote: > >>> On 20.01.17 at 14:46, wrote: > > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote: > >> >>> On 20.01.17 at 12:43, wrote: > >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote: > >> >> >>> On 20.01.17 at 02:34, wrote: > >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the > >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both > >> parts)? > > > > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is > > OK for you? And I can agree that this is better naming. > > Again, I don't see why you would need TRAMPOLINE_STACK_SPACE. If we use TRAMPOLINE_SPACE only for both trampoline and its stack then ASSERT() is not very reliable. There is chance that trampoline code will fill all space specified in TRAMPOLINE_SPACE and then there will be no space for stack at all. However, I can agree that chance is small if we assume 64 KiB space for trampoline and trampoline size is about 10 KiB right now. > >> >> two defines - except in the link time assertion you always use > >> >> the sum of the two. > >> >> > >> >> > +#define MBI_SIZE(2 * PAGE_SIZE) > >> >> > >> >> On top of Doug's question - if it is needed at all, what does this > >> > > >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly > >> > realize that there is following memory layout from top to bottom: > >> > > >> > +--+ > >> > | TRAMPOLINE_STACK | > >> > +--+ > >> > |TRAMPOLINE| > >> > +--+ > >> > |mbi struct| > >> > +--+ > >> > > >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)? > >> > > >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments, > >> > memory map and other minor things. > >> > >> Even with a couple of dozen modules passed? But the primary > > > > Why not? The biggest thing is memory map. The rest are mostly > > command line strings and a few pointers. Modules itself live > > in different memory regions. > > Command line string may get lengthy. Do you think that we should have more than 8 KiB there? Anyway, I am more afraid about memory map size here. > >> question was left unanswered anyway: Does this need placing in > >> the low megabyte at all? And even if it does, especially if you > > > > I do not think so. I do not expect that anything in trampoline code > > touches it. So, we can put it anywhere below 4 GiB. However, then > > we need an allocator to properly allocate mbi struct region. And > > at this boot stage this is not an easy thing. > > Depending for how long you need that data to stay around, there IIRC, it is needed only during init phase. Probably later it can be dropped. > may be places to put it without much risk of overflowing anything. I am not sure about which places do you think. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
>>> On 20.01.17 at 15:43, wrote: > On Fri, Jan 20, 2017 at 07:10:32AM -0700, Jan Beulich wrote: >> >>> On 20.01.17 at 14:46, wrote: >> > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote: >> >> >>> On 20.01.17 at 12:43, wrote: >> >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote: >> >> >> >>> On 20.01.17 at 02:34, wrote: >> >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the >> >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both >> >> parts)? >> > >> > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is >> > OK for you? And I can agree that this is better naming. >> >> Again, I don't see why you would need TRAMPOLINE_STACK_SPACE. > > If we use TRAMPOLINE_SPACE only for both trampoline and its stack > then ASSERT() is not very reliable. There is chance that trampoline > code will fill all space specified in TRAMPOLINE_SPACE and then there > will be no space for stack at all. However, I can agree that chance > is small if we assume 64 KiB space for trampoline and trampoline size > is about 10 KiB right now. The ASSERT() is the only place you need the stack size, so just encode (subtract) it there (like iirc Doug had done). >> >> >> two defines - except in the link time assertion you always use >> >> >> the sum of the two. >> >> >> >> >> >> > +#define MBI_SIZE(2 * PAGE_SIZE) >> >> >> >> >> >> On top of Doug's question - if it is needed at all, what does this >> >> > >> >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly >> >> > realize that there is following memory layout from top to bottom: >> >> > >> >> > +--+ >> >> > | TRAMPOLINE_STACK | >> >> > +--+ >> >> > |TRAMPOLINE| >> >> > +--+ >> >> > |mbi struct| >> >> > +--+ >> >> > >> >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)? >> >> > >> >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments, >> >> > memory map and other minor things. >> >> >> >> Even with a couple of dozen modules passed? But the primary >> > >> > Why not? The biggest thing is memory map. The rest are mostly >> > command line strings and a few pointers. Modules itself live >> > in different memory regions. >> >> Command line string may get lengthy. > > Do you think that we should have more than 8 KiB there? Anyway, > I am more afraid about memory map size here. The question is how flexible we want to be. If the size is fixed, you need to make your code stop using space beyond that size. >> >> question was left unanswered anyway: Does this need placing in >> >> the low megabyte at all? And even if it does, especially if you >> > >> > I do not think so. I do not expect that anything in trampoline code >> > touches it. So, we can put it anywhere below 4 GiB. However, then >> > we need an allocator to properly allocate mbi struct region. And >> > at this boot stage this is not an easy thing. >> >> Depending for how long you need that data to stay around, there > > IIRC, it is needed only during init phase. Probably later it can be dropped. That's way too imprecise. >> may be places to put it without much risk of overflowing anything. > > I am not sure about which places do you think. There are a number of relatively large internal buffers which could be used for this purpose if the uses of the MBI data all live before the first use of whichever such buffer we would select as victim. Otherwise, just go down from e.g. trampoline+60k until you reach trampoline_end. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On 1/19/17 8:34 PM, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper > --- > v12 - suggestions/fixes: > - rename __efi64_start to __efi64_mb2_start > (suggested by Andrew Cooper), Andrew actually asked for __mb2_efi64_start > + > +__efi64_mb2_start: here. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On 20/01/17 19:04, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: >> This way Xen can be loaded on EFI platforms using GRUB2 and >> other boot loaders which support multiboot2 protocol. >> >> Signed-off-by: Daniel Kiper >> --- >> v12 - suggestions/fixes: >> - rename __efi64_start to __efi64_mb2_start >> (suggested by Andrew Cooper), > Andrew actually asked for __mb2_efi64_start I can't say that I am overly fussed which way around this ends up. I certainly won't insist on changing. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On 1/19/17 8:34 PM, Daniel Kiper wrote: > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 62c010e..c1285ad 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > + > +efi_exit_boot(ImageHandle, SystemTable); > + > +/* Return highest allocated memory address below 1 MiB. */ > +return cfg.addr + cfg.size; So my comment about overwriting memory on 02/10 was spot on but made the incorrect conclusion that it was before hand and not after. And here's the issue. I believe what you meant to do was: return cfg.addr + MBI_SIZE; I can't see how this booted for you with OVMF because for all the different versions I've tried with the original code its writing over reserved memory that QEMU uses for the graphics buffers. Which immediately results in the trampolines being overwritten with console data. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 02:34:35PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > > index 62c010e..c1285ad 100644 > > --- a/xen/arch/x86/efi/efi-boot.h > > +++ b/xen/arch/x86/efi/efi-boot.h > > > + > > +efi_exit_boot(ImageHandle, SystemTable); > > + > > +/* Return highest allocated memory address below 1 MiB. */ > > +return cfg.addr + cfg.size; > > So my comment about overwriting memory on 02/10 was spot on but made the > incorrect conclusion that it was before hand and not after. And here's > the issue. I believe what you meant to do was: > > return cfg.addr + MBI_SIZE; Errr... Sorry, this is the issue which I knew but I forgot to fix in v12. > I can't see how this booted for you with OVMF because for all the > different versions I've tried with the original code its writing over > reserved memory that QEMU uses for the graphics buffers. Which > immediately results in the trampolines being overwritten with console data. It booted without any complain... Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
