Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-30 Thread Daniel Kiper 
On Wed, Nov 30, 2016 at 06:59:57AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 14:45,  wrote:
> > On Fri, Nov 25, 2016 at 12:50:55AM -0700, Jan Beulich wrote:
> >> >>> On 24.11.16 at 22:44,  wrote:
> >> > On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
> >> >> >>> On 23.11.16 at 19:52,  wrote:
> >> >> > Always use add/sub 1 in preference to inc and dec.  They are the same
> >> >> > length to encode in 64bit, and avoids a pipeline stall from a merge of
> >> >> > the eflags register.
> >> >>
> >> >> What you say regarding length not true - add/sub need to encode
> >> >> the immediate somewhere (even if the operand was a register,
> >> >> inc/dec would still be smaller than add/sub, just not by as much as
> >> >> in 32-bit code). And the pipeline stall, afaik, affects only rather old
> >> >> processors.
> >> >
> >> > Intel 64 and IA-32 Architectures Optimization Reference Manual, section
> >> > 3.5.1.1, Use of the INC and DEC Instructions says nothing about 
> >> > exceptions.
> >>
> >> Which by itself is suspicious, as the dependency issue had been
> >> introduced only in (iirc) Pentium4. And anyway, this is a general
> >
> > Hmmm... Interesting... It looks that INC/DEC behavior has not changed since
> > the beginning (why it would change? It would not make sense).
>
> Please properly disambiguate "behavior": Architectural behavior of
> course can't change. Performance, otoh, has changed many times.

Right!

> And the resource dependency issue did appear only once the
> pipelining of instructions was sophisticated enough, but not good
> enough yet to track (as a dependency) EFLAGS.CF separately from
> the other arithmetic result flags.

OK, make sense right now. Thanks for explanation.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-30 Thread Jan Beulich 
>>> On 30.11.16 at 14:45,  wrote:
> On Fri, Nov 25, 2016 at 12:50:55AM -0700, Jan Beulich wrote:
>> >>> On 24.11.16 at 22:44,  wrote:
>> > On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
>> >> >>> On 23.11.16 at 19:52,  wrote:
>> >> > Always use add/sub 1 in preference to inc and dec.  They are the same
>> >> > length to encode in 64bit, and avoids a pipeline stall from a merge of
>> >> > the eflags register.
>> >>
>> >> What you say regarding length not true - add/sub need to encode
>> >> the immediate somewhere (even if the operand was a register,
>> >> inc/dec would still be smaller than add/sub, just not by as much as
>> >> in 32-bit code). And the pipeline stall, afaik, affects only rather old
>> >> processors.
>> >
>> > Intel 64 and IA-32 Architectures Optimization Reference Manual, section
>> > 3.5.1.1, Use of the INC and DEC Instructions says nothing about exceptions.
>>
>> Which by itself is suspicious, as the dependency issue had been
>> introduced only in (iirc) Pentium4. And anyway, this is a general
> 
> Hmmm... Interesting... It looks that INC/DEC behavior has not changed since
> the beginning (why it would change? It would not make sense).

Please properly disambiguate "behavior": Architectural behavior of
course can't change. Performance, otoh, has changed many times.
And the resource dependency issue did appear only once the
pipelining of instructions was sophisticated enough, but not good
enough yet to track (as a dependency) EFLAGS.CF separately from
the other arithmetic result flags.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-30 Thread Daniel Kiper 
On Fri, Nov 25, 2016 at 12:50:55AM -0700, Jan Beulich wrote:
> >>> On 24.11.16 at 22:44,  wrote:
> > On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
> >> >>> On 23.11.16 at 19:52,  wrote:
> >> > On 29/09/16 22:42, Daniel Kiper wrote:
> >
> > [...]
> >
> >> >> +.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
> >> >> +
> >> >> +/*
> >> >> + * Yes, store that info in skip_realmode variable. I agree that
> >> >> + * its name is a bit unfortunate in this context, however, by 
> >> >> the
> >> >> + * way we disable real mode and other legacy stuff which should
> >> >> + * not be run on EFI platforms.
> >> >> + */
> >> >> +incbskip_realmode(%rip)
> >> >
> >> > Always use add/sub 1 in preference to inc and dec.  They are the same
> >> > length to encode in 64bit, and avoids a pipeline stall from a merge of
> >> > the eflags register.
> >>
> >> What you say regarding length not true - add/sub need to encode
> >> the immediate somewhere (even if the operand was a register,
> >> inc/dec would still be smaller than add/sub, just not by as much as
> >> in 32-bit code). And the pipeline stall, afaik, affects only rather old
> >> processors.
> >
> > Intel 64 and IA-32 Architectures Optimization Reference Manual, section
> > 3.5.1.1, Use of the INC and DEC Instructions says nothing about exceptions.
>
> Which by itself is suspicious, as the dependency issue had been
> introduced only in (iirc) Pentium4. And anyway, this is a general

Hmmm... Interesting... It looks that INC/DEC behavior has not changed since
the beginning (why it would change? It would not make sense). Though my oldest
book about 80286, 80386 and i486 CPUS (printed in 1991 and it is based on
eighties Intel documentation) says nothing about such issues. So, I have
a feeling that this issue appeared (or it existed earlier but it was not
documented minor problem) when x86 implementation changed from 100% in
silicon to mostly (???) microcode. IIRC, it happened around Pentium but
I am not sure.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-24 Thread Jan Beulich 
>>> On 24.11.16 at 22:44,  wrote:
> On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
>> >>> On 23.11.16 at 19:52,  wrote:
>> > On 29/09/16 22:42, Daniel Kiper wrote:
> 
> [...]
> 
>> >> +.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
>> >> +
>> >> +/*
>> >> + * Yes, store that info in skip_realmode variable. I agree that
>> >> + * its name is a bit unfortunate in this context, however, by the
>> >> + * way we disable real mode and other legacy stuff which should
>> >> + * not be run on EFI platforms.
>> >> + */
>> >> +incbskip_realmode(%rip)
>> >
>> > Always use add/sub 1 in preference to inc and dec.  They are the same
>> > length to encode in 64bit, and avoids a pipeline stall from a merge of
>> > the eflags register.
>>
>> What you say regarding length not true - add/sub need to encode
>> the immediate somewhere (even if the operand was a register,
>> inc/dec would still be smaller than add/sub, just not by as much as
>> in 32-bit code). And the pipeline stall, afaik, affects only rather old
>> processors.
> 
> Intel 64 and IA-32 Architectures Optimization Reference Manual, section
> 3.5.1.1, Use of the INC and DEC Instructions says nothing about exceptions.

Which by itself is suspicious, as the dependency issue had been
introduced only in (iirc) Pentium4. And anyway, this is a general
recommendation of theirs, i.e. something to consider when
intending to run well everywhere. Such general recommendation
by their very nature don't consider model specific differences.

> So, it looks that this applies to all x86 CPUs. However, as I said earlier,
> I am not convinced that we should consider such nuances here. incb reads
> better at least for me.

I agree, and I hope we can get Andrew to agree too.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-24 Thread Daniel Kiper 
On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote:
> >>> On 23.11.16 at 19:52,  wrote:
> > On 29/09/16 22:42, Daniel Kiper wrote:

[...]

> >> +.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
> >> +
> >> +/*
> >> + * Yes, store that info in skip_realmode variable. I agree that
> >> + * its name is a bit unfortunate in this context, however, by the
> >> + * way we disable real mode and other legacy stuff which should
> >> + * not be run on EFI platforms.
> >> + */
> >> +incbskip_realmode(%rip)
> >
> > Always use add/sub 1 in preference to inc and dec.  They are the same
> > length to encode in 64bit, and avoids a pipeline stall from a merge of
> > the eflags register.
>
> What you say regarding length not true - add/sub need to encode
> the immediate somewhere (even if the operand was a register,
> inc/dec would still be smaller than add/sub, just not by as much as
> in 32-bit code). And the pipeline stall, afaik, affects only rather old
> processors.

Intel 64 and IA-32 Architectures Optimization Reference Manual, section
3.5.1.1, Use of the INC and DEC Instructions says nothing about exceptions.
So, it looks that this applies to all x86 CPUs. However, as I said earlier,
I am not convinced that we should consider such nuances here. incb reads
better at least for me.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-24 Thread Daniel Kiper 
On Wed, Nov 23, 2016 at 06:52:27PM +, Andrew Cooper wrote:
> On 29/09/16 22:42, Daniel Kiper wrote:

[...]

> > +vga_text_buffer:
> > +.long   0xb8000
>
> Why is this turned into a variable?

We must disable VGA accesses during runtime on platforms which does
not have one like e.g. EFI. That is why I have added variable here.
It seems to me that it is the simplest method to do that.

> >  .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
> >  .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
> > +.Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!"
> > +.Lbad_ldr_nst: .asciz "ERR: EFI SystemTable is not provided by bootloader!"
> > +.Lbad_ldr_nih: .asciz "ERR: EFI ImageHandle is not provided by bootloader!"
> > +.Lbad_efi_msg: .asciz "ERR: EFI IA-32 platforms are not supported!"
> >
> >  .section .init.text, "ax", @progbits
> >
> >  bad_cpu:
> >  mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
> > -jmp print_err
> > +jmp .Lget_vtb
> >  not_multiboot:
> >  mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
> > -print_err:
> > -mov $0xB8000,%edi  # VGA framebuffer
> > -1:  mov (%esi),%bl
> > +jmp .Lget_vtb
> > +.Lmb2_no_st:
> > +mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message
> > +jmp .Lget_vtb
> > +.Lmb2_no_ih:
> > +mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message
> > +jmp .Lget_vtb
> > +.Lmb2_no_bs:
> > +mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message
> > +xor %edi,%edi   # No VGA text buffer
> > +jmp .Lsend_chr
> > +.Lmb2_efi_ia_32:
> > +mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message
> > +xor %edi,%edi   # No VGA text buffer
> > +jmp .Lsend_chr
> > +.Lget_vtb:
> > +mov sym_phys(vga_text_buffer),%edi
> > +.Lsend_chr:
> > +mov (%esi),%bl
> >  test%bl,%bl# Terminate on '\0' sentinel
> >  je  .Lhalt
> >  mov $0x3f8+5,%dx   # UART Line Status Register
> > @@ -123,13 +159,182 @@ print_err:
> >  mov $0x3f8+0,%dx   # UART Transmit Holding Register
> >  mov %bl,%al
> >  out %al,%dx# Send a character over the serial line
> > -movsb  # Write a character to the VGA framebuffer
> > +test%edi,%edi  # Is the VGA text buffer available?
> > +jz  .Lsend_chr
> > +movsb  # Write a character to the VGA text buffer
> >  mov $7,%al
> > -stosb  # Write an attribute to the VGA framebuffer
> > -jmp 1b
> > +stosb  # Write an attribute to the VGA text buffer
> > +jmp .Lsend_chr
> >  .Lhalt: hlt
> >  jmp .Lhalt
> >
> > +.code64
> > +
> > +__efi64_start:
> > +cld
> > +
> > +/* VGA is not available on EFI platforms. */
> > +movl   $0,vga_text_buffer(%rip)
> > +
> > +/* Check for Multiboot2 bootloader. */
> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +je  .Lefi_multiboot2_proto
> > +
> > +/* Jump to not_multiboot after switching CPU to x86_32 mode. */
> > +lea not_multiboot(%rip),%edi
> > +jmp x86_32_switch
> > +
> > +.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
> > +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
> > +
> > +/*
> > + * Yes, store that info in skip_realmode variable. I agree that
> > + * its name is a bit unfortunate in this context, however, by the
> > + * way we disable real mode and other legacy stuff which should
> > + * not be run on EFI platforms.
> > + */
> > +incbskip_realmode(%rip)
>
> Always use add/sub 1 in preference to inc and dec.  They are the same
> length to encode in 64bit, and avoids a pipeline stall from a merge of
> the eflags register.

Nice but does it pays here? I am not convinced.

> > +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
> > +

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-24 Thread Jan Beulich 
>>> On 23.11.16 at 19:52,  wrote:
> On 29/09/16 22:42, Daniel Kiper wrote:
>> @@ -100,20 +107,49 @@ multiboot2_header_start:
>>  gdt_boot_descr:
>>  .word   6*8-1
>>  .long   sym_phys(trampoline_gdt)
>> +.long   0 /* Needed for 64-bit lgdt */
>> +
>> +cs32_switch_addr:
>> +.long   sym_phys(cs32_switch)
>> +.word   BOOT_CS32
>> +
>> +.align 4
>> +vga_text_buffer:
>> +.long   0xb8000
> 
> Why is this turned into a variable?

This gets zapped to zero near __efi64_start.

>> +.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
>> +
>> +/*
>> + * Yes, store that info in skip_realmode variable. I agree that
>> + * its name is a bit unfortunate in this context, however, by the
>> + * way we disable real mode and other legacy stuff which should
>> + * not be run on EFI platforms.
>> + */
>> +incbskip_realmode(%rip)
> 
> Always use add/sub 1 in preference to inc and dec.  They are the same
> length to encode in 64bit, and avoids a pipeline stall from a merge of
> the eflags register.

What you say regarding length not true - add/sub need to encode
the immediate somewhere (even if the operand was a register,
inc/dec would still be smaller than add/sub, just not by as much as
in 32-bit code). And the pipeline stall, afaik, affects only rather old
processors.

>> +x86_32_switch:
>> +cli
>> +
>> +/* Initialize GDTR. */
>> +lgdtgdt_boot_descr(%rip)
>> +
>> +/* Reload code selector. */
>> +ljmpl   *cs32_switch_addr(%rip)
> 
> This would be cleaner and shorter as
> 
> push $BOOT_CS32
> push $cs32_switch

I'm not sure: For one this would need to be $sym_phys(cs32_switch).
And with that I wouldn't be certain the relocation gets expressed
correctly. But yes, if it works, I too would prefer this.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-11-23 Thread Andrew Cooper 
On 29/09/16 22:42, 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 
> ---
> 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  |  260 
> ++---
>  xen/arch/x86/efi/efi-boot.h   |   54 +++-
>  xen/arch/x86/efi/stub.c   |   38 ++
>  xen/arch/x86/x86_64/asm-offsets.c |2 +
>  xen/arch/x86/xen.lds.S|4 +-
>  xen/common/efi/boot.c |   11 ++
>  6 files changed, 346 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index d423fd8..0155b32 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -89,6 +89,13 @@ multiboot2_header_start:
> 0, /* Number of the lines - no preference. */ \
> 0  /* Number of bits per pixel - no preference. */
>  
> +/* Inhibit bootloader from calling ExitBootServices(). */
> +mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
> +
> +/* EFI64 entry point. */
> +mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
> +   sym_phys(__efi64_start)
> +
>  /* Multiboot2 header end tag. */
>  mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
>  .Lmultiboot2_header_end:
> @@ -100,20 +107,49 @@ multiboot2_header_start:
>  gdt_boot_descr:
>  .word   6*8-1
>  .long   sym_phys(trampoline_gdt)
> +.long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long

[Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

2016-09-29 Thread Daniel Kiper 
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
---
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  |  260 ++---
 xen/arch/x86/efi/efi-boot.h   |   54 +++-
 xen/arch/x86/efi/stub.c   |   38 ++
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   11 ++
 6 files changed, 346 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d423fd8..0155b32 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0  /* Number of bits per pixel - no preference. */
 
+/* Inhibit bootloader from calling ExitBootServices(). */
+mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+/* EFI64 entry point. */
+mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 .Lmultiboot2_header_end:
@@ -100,20 +107,49 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+cs32_switch_addr:
+.long   sym_phys(cs32_switch)
+.word   BOOT_CS32
+
+.align 4
+vga_text_buffer:
+.long   0xb8000
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_nbs: .asciz "ERR: Bootloader shutdown EFI x64 boot services!"