Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > Relocator
> > will set lower parts of %rax and %rbx accordingly to multiboot2
> > specification.
> > On the other hand processor mode, just before jumping into loaded image,
> > will
> > be set accordingly to Unified Extensible Firmware Interface Specification,
> > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> > loaded image will be able to use EFI boot services without any issues.
> >
> > If idea is accepted I will prepare grub_relocator32_efi relocator too.

OK, as I can see idea in general is accepted. Do you want
grub_relocator32_efi in 2.02 or 2.03 is OK?

> > Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com <javascript:;>>
> > ---
> > v3 - suggestions/fixes:
> >- reuse grub-core/lib/i386/relocator64.S code
> >  instead of creating separate assembly file
> >  (suggested by Vladimir 'phcoder' Serbinenko),
> >- grub_multiboot_boot() cleanup
> >  (suggested by Vladimir 'phcoder' Serbinenko),
> >- reuse multiboot_header_tag_entry_address struct instead
> >  of creating new one for EFI 64-bit entry point
> >  (suggested by Vladimir 'phcoder' Serbinenko).
> > ---
> >  grub-core/lib/i386/relocator.c|   48
> > ++
> >  grub-core/lib/i386/relocator64.S  |3 +++
> >  grub-core/loader/multiboot.c  |   51
> > +
> >  grub-core/loader/multiboot_mbi2.c |   19 +++---
> >  include/grub/i386/multiboot.h |   11 
> >  include/grub/i386/relocator.h |   21 +++
> >  include/multiboot2.h  |1 +
> >  7 files changed, 145 insertions(+), 9 deletions(-)
> >
> > diff --git a/grub-core/lib/i386/relocator.c
> > b/grub-core/lib/i386/relocator.c
> > index 71dd4f0..2b0c260 100644
> > --- a/grub-core/lib/i386/relocator.c
> > +++ b/grub-core/lib/i386/relocator.c
> > @@ -69,6 +69,13 @@ extern grub_uint64_t grub_relocator64_rsi;
> >  extern grub_addr_t grub_relocator64_cr3;
> >  extern struct grub_i386_idt grub_relocator16_idt;
> >
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __x86_64__
> > +extern grub_uint8_t grub_relocator64_efi_start;
> > +extern grub_uint8_t grub_relocator64_efi_end;
> > +#endif
> > +#endif
> > +
> >
> Can we move this and all to a separate file to avoid too many #ifdef ?

Do you think about grub-core/lib/i386/relocator-efi.c or something like that?
If yes then I do not think it is a problem.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:26:06PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > Add tags used to pass ImageHandle to loaded image if requested.
> > It is used by at least ExitBootServices() function.
> >
> > Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com <javascript:;>>
> > ---
> > v3 - suggestions/fixes:
> >- mbi EFI related stuff size calculation
> >  should depend on target architecture
> >  (suggested by Konrad Rzeszutek Wilk),
> >- use plain type instead of pointer
> >  dereference as sizeof() argument
> >  (suggested by Konrad Rzeszutek Wilk),
> >- improve commit message
> >  (suggested by Konrad Rzeszutek Wilk).
> > ---
> >  grub-core/loader/multiboot_mbi2.c |   50
> > ++---
> >  include/multiboot2.h  |   16 
> >  2 files changed, 57 insertions(+), 9 deletions(-)
> >
> > diff --git a/grub-core/loader/multiboot_mbi2.c
> > b/grub-core/loader/multiboot_mbi2.c
> > index a3dca90..7591edc 100644
> > --- a/grub-core/loader/multiboot_mbi2.c
> > +++ b/grub-core/loader/multiboot_mbi2.c
> > @@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char
> > *filename)
> >   case MULTIBOOT_TAG_TYPE_NETWORK:
> >   case MULTIBOOT_TAG_TYPE_EFI_MMAP:
> >   case MULTIBOOT_TAG_TYPE_EFI_BS:
> > + case MULTIBOOT_TAG_TYPE_EFI32_IH:
> > + case MULTIBOOT_TAG_TYPE_EFI64_IH:
> > break;
> >
> >   default:
> > @@ -407,16 +409,22 @@ grub_multiboot_get_mbi_size (void)
> >  + grub_get_multiboot_mmap_count ()
> >  * sizeof (struct multiboot_mmap_entry)),
> > MULTIBOOT_TAG_ALIGN)
> >  + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer),
> > MULTIBOOT_TAG_ALIGN)
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __i386__
> >  + ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih),
> > MULTIBOOT_TAG_ALIGN)
> > +#endif
> > +#ifdef __x86_64__
> >  + ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih),
> > MULTIBOOT_TAG_ALIGN)
> > +#endif
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > +   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > +#endif
> >
> It doesn't need to be exact. It's just an upper bound. Feel free to
> simplify knowing this, removing few #ifdef.

OK.

> >  + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
> > + sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
> >  + acpiv2_size ()
> >  + net_size ()
> > -#ifdef GRUB_MACHINE_EFI
> > -+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > -   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > -#endif
> >  + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
> >  + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
> >  }
> > @@ -907,11 +915,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
> >
> >if (keep_bs)
> >  {
> > -  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > -  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > -  tag->size = sizeof (struct multiboot_tag);
> > -  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > -   / sizeof (grub_properly_aligned_t);
> > +  {
> > +   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > +   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > +   tag->size = sizeof (struct multiboot_tag);
> > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > + / sizeof (grub_properly_aligned_t);
> > +  }
> > +
> > +#ifdef __i386__
> > +  {
> > +   struct multiboot_tag_efi32_ih *tag = (struct
> > multiboot_tag_efi32_ih *) ptrorig;
> > +   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
> > +   tag->size = sizeof (struct multiboot_tag_efi32_ih);
> > +   tag->pointer = (grub_addr_t) grub_efi_image_handle;
> > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > + / sizeof (grub_properly_aligned_t);
> > +  }
> > +#endif
> > +
> > +#ifdef __x86_64__
> > +  {
> > +   struct multiboot_tag_efi64_ih *tag = (struct
> > multibo

Re: [Xen-devel] Request to revert superpage adjustments

[Daniel Kiper]

On Fri, Mar 11, 2016 at 09:35:19AM -0500, Konrad Rzeszutek Wilk wrote:
> > >>  Nor would
> > >> that deal with avoiding reserved regions not too far above 1Mb,
> > >> since at best the main payload can be relocatable (but certainly
> > >> not the binary seen by the boot loader, as at least multiboot1
> > >> doesn't support anything like that).
> > >
> > > The only reason Xen sits at the 1MB boundary is because of its ELF header.
> > >
> > > A plain binary with a multiboot header has no such restriction, although
> > > we flag an interested to have 4k alignment using the multiboot flags.
> > > There is no technical limitation causing Xen to be linked to run at 1MB;
> > > its just the way its alway been.  There is nothing preventing the entry
> > > point becoming properly relocatable.
>
> And one can make it be at 2MB - which is what Daniel's patches did.

IIRC, with my patches it could be anything which is multiple of 2 MiB.

> (CC-ing Daniel in case I got it wrong). We also needed GRUB2 patches
> to take into account relocating Xen at a different location.

Konrad is correct.

By the way, I would like to mention that probably next week all required
multiboot2 functionality will be available in upstream git tree and later
in GRUB2 2.02 release. This means that new multiboot2 features are almost
set in stone.

> > Without proper container format, how would the boot loader
> > know where to place the binary, or how to relocate it if it doesn't
> > get placed at its linked address? The only alternatives I see in
> > grub1 are a.out and a kludge of a.out, both of which - at the first
> > glance - also don't appear to do any relocation. And for the Linux
> > variant, as said, it doesn't look like it's compatible with us needing
> > multiple modules.

multiboot and multiboot2 (without my extensions) put image exactly at address
specified in ELF or multiboot2 header. This means that boot loader is not able
to relocate image during load. I do not mention that current version of Xen
(without my EFI/multiboot2 patches) is not able to understand relocation
(if it would be provided/executed by loader) too.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

On Fri, Mar 11, 2016 at 06:33:15PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> >
> > [...]
> >
> > > multiboot2 spec is a rolling update.
> >
> > OK. So, I think that we should do this in that way:
> >   - apply this patch series after polishing;
> > I hope that it will happen next week,
>
>   - update multiboot2 doc,
> >   - add grub_relocator32_efi;
> > should it be 2.02 goal?
> >
> Only if it's small
>
> >   - agree and add support for ELF relocations;
> > should it be 2.02 goal?
> >
> Full ELF relocations are definitely not for 2.02
>
> >
> > Does it make sense?
> >
> yes

Great! Stay tuned... I will polish and repost this patch series next week.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko wrote:

[...]

> multiboot2 spec is a rolling update.

OK. So, I think that we should do this in that way:
  - apply this patch series after polishing;
I hope that it will happen next week,
  - update multiboot2 doc,
  - add grub_relocator32_efi;
should it be 2.02 goal?
  - agree and add support for ELF relocations;
should it be 2.02 goal?

Does it make sense?

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:41:26PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platforms. It is possible because memory regions are placed at predictable
> > addresses (though I was not able to find any spec which says that it is
> > strong requirement, so, it looks that it is just a goodwill of hardware
> > designers). However, EFI platforms are more volatile. Even if required
> > memory regions live at specific addresses then they are sometimes simply
> > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> > OVMF). This means that you are not able to simply set up final image
> > destination on build time. You have to provide method to relocate image
> > contents to real load address which is usually different than load address
> > specified in ELF and multiboot2 headers.
> >
> > This patch provides all needed machinery to do self relocation in image
> > code.
> > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load
> > addr),
> > align (required image alignment), preference (it says which memory regions
> > are
> > preferred by image, e.g. none, low, high) from
> > multiboot_header_tag_relocatable
> > header tag contained in binary. Later loader tries to fulfill request (not
> > only
> > that one) and if it succeeds then it informs image about real load address
> > via
> > multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> > from now executable must cope with relocations itself using whole static
> > and dynamic knowledge provided by boot loader.
> >
> > This patch does not provide functionality which could do relocations using
> > ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and
> > Vladimir
> > 'phcoder' Serbinenko to investigate that thing. It looks that relevant
> > machinery
> > could be added to existing code (including this patch) without huge effort.
> > Additionally, ELF relocation could live in parallel with self relocation
> > provided
> > by this patch. However, during research I realized that first of all we
> > should
> > establish the details how ELF relocatable image should look like and how
> > it should
> > be build. At least to build proper test/example files.
> >
> > As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF
> > files.
> > Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
> > option.
> > However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> > GNU_EH_FRAME
> > program headers) and it could be quite difficult to drop them (Hmmm... Is
> > it
> > possible to build it properly with custom ld script?).
>
> How big are they? Are they a real problem?

ET_DYN file is ~2.5 times bigger then normal ET_EXEC (I has checked 
multiboot2.elf
from GRUB2). There is a chance that we can ignore most of stuff in ET_DYN, 
however,
it does not look nice. IMO, image should have only what is needed by loader.

> > So, I have checked ET_EXEC
> > file type. Sadly in this case linker by default resolves all local symbol
> > relocations
> > and removes relocation related sections. Fortunately it is possible to
> > leave them
> > as is with simple -q/--emit-relocs ld option. However, output file is
> > quite fragile
> > and any operation on it should be done with great care (e.g. strip should
> > be called
> > with --strip-unneeded option). So, this solution is not perfect too. It
> > means that
> > maybe we should look for better solution. However, I think that we should
> > not use
> > any custom tools and focus on functionalities provided by compiler and
> > binutils.
> > In this context ld scripts looks quite promising but maybe you have better
> > solutions.
> > So, what do you think about that?
> >
>  Another possibility is to use intermediary .o files like we do for modules
> and like Linux does for modules AFAIR.

Correct but I think that it would be better to have normal ET_EXEC or ET_DYN 
file.

> > This patch was tested with Xen image which uses that functionality.
> > However, this Xen
> > feature is still under development and new patchset will be released in
> > about 3-4 weeks.
> >
> > Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com <javascript:;>>
> > ---
> > v3

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:44:31PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platforms. It is possible because memory regions are placed at predictable
> > addresses (though I was not able to find any spec which says that it is
> > strong requirement, so, it looks that it is just a goodwill of hardware
> > designers). However, EFI platforms are more volatile. Even if required
> > memory regions live at specific addresses then they are sometimes simply
> > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> > OVMF). This means that you are not able to simply set up final image
> > destination on build time. You have to provide method to relocate image
> > contents to real load address which is usually different than load address
> > specified in ELF and multiboot2 headers.
> >
> > This patch provides all needed machinery to do self relocation in image
> > code.
> > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load
> > addr),
> > align (required image alignment), preference (it says which memory regions
> > are
> > preferred by image, e.g. none, low, high) from
> > multiboot_header_tag_relocatable
> > header tag contained in binary. Later loader tries to fulfill request (not
> > only
> > that one) and if it succeeds then it informs image about real load address
> > via
> > multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> > from now executable must cope with relocations itself using whole static
> > and dynamic knowledge provided by boot loader.
> >
> > This patch does not provide functionality which could do relocations using
> > ELF relocation data.
>
> Can you add a check that image doesn't have any relocation entries? So that
> we fail nicely rather than loading half-working binary?

Make sense. I will do that.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Fri, Mar 11, 2016 at 04:42:27PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper <daniel.ki...@oracle.com> wrote:
>
> > On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> > > On Wednesday, March 2, 2016, Daniel Kiper <daniel.ki...@oracle.com
> > <javascript:;>> wrote:
> > >
> > > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> > platforms
> > > > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > > > Relocator
> > > > will set lower parts of %rax and %rbx accordingly to multiboot2
> > > > specification.
> > > > On the other hand processor mode, just before jumping into loaded
> > image,
> > > > will
> > > > be set accordingly to Unified Extensible Firmware Interface
> > Specification,
> > > > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services.
> > This way
> > > > loaded image will be able to use EFI boot services without any issues.
> > > >
> > > > If idea is accepted I will prepare grub_relocator32_efi relocator too.
> >
> > OK, as I can see idea in general is accepted. Do you want
> > grub_relocator32_efi in 2.02 or 2.03 is OK?
> >
> Is there already a user for it? Or someone who is expected to adopt it
> shortly?

I have not heard anything about that. So, safely we can defer it to 2.03.
We should just reserve relevant numbers for required constants and say
somewhere that this feature is not implemented yet.

Daniel

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

[Xen-devel] [GRUB2 PATCH v5 0/4] multiboot2: Add two extensions

[Daniel Kiper]

Hi,

This patch series:
  - enables EFI boot services usage in loaded images
by multiboot2 protocol,
  - add support for multiboot2 protocol compatible
relocatable images.

Daniel

 grub-core/Makefile.core.def   |1 +
 grub-core/lib/i386/relocator64.S  |   11 
 grub-core/lib/x86_64/efi/relocator.c  |   76 
 grub-core/loader/i386/multiboot_mbi.c |   13 -
 grub-core/loader/multiboot.c  |   62 
 grub-core/loader/multiboot_elfxx.c|  133 
+-
 grub-core/loader/multiboot_mbi2.c |  248 
--
 include/grub/i386/multiboot.h |   11 
 include/grub/i386/relocator.h |   21 +++
 include/grub/multiboot.h  |   22 ++-
 include/multiboot2.h  |   41 +
 11 files changed, 503 insertions(+), 136 deletions(-)

Daniel Kiper (4):
  i386/relocator: Add grub_relocator64_efi relocator
  multiboot2: Add tags used to pass ImageHandle to loaded image
  multiboot2: Do not pass memory maps to image if EFI boot services are 
enabled
  multiboot2: Add support for relocatable images


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

[Xen-devel] [GRUB2 PATCH v5 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v4 - suggestions/fixes:
   - reduce number of #ifdefs in grub_multiboot_get_mbi_size()
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - mbi EFI related stuff size calculation
 should depend on target architecture
 (suggested by Konrad Rzeszutek Wilk),
   - use plain type instead of pointer
 dereference as sizeof() argument
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/multiboot_mbi2.c |   42 ++---
 include/multiboot2.h  |   16 ++
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index a3dca90..6c04402 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char *filename)
  case MULTIBOOT_TAG_TYPE_NETWORK:
  case MULTIBOOT_TAG_TYPE_EFI_MMAP:
  case MULTIBOOT_TAG_TYPE_EFI_BS:
+ case MULTIBOOT_TAG_TYPE_EFI32_IH:
+ case MULTIBOOT_TAG_TYPE_EFI64_IH:
break;
 
  default:
@@ -407,13 +409,15 @@ grub_multiboot_get_mbi_size (void)
 + grub_get_multiboot_mmap_count ()
 * sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
 + acpiv2_size ()
 + net_size ()
 #ifdef GRUB_MACHINE_EFI
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+ efi_mmap_size, MULTIBOOT_TAG_ALIGN)
 #endif
@@ -907,11 +911,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 
   if (keep_bs)
 {
-  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
-  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
-  tag->size = sizeof (struct multiboot_tag);
-  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
+  {
+   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
+   tag->size = sizeof (struct multiboot_tag);
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+
+#ifdef __i386__
+  {
+   struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
+   tag->size = sizeof (struct multiboot_tag_efi32_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
+
+#ifdef __x86_64__
+  {
+   struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
+   tag->size = sizeof (struct multiboot_tag_efi64_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
 }
 #endif
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index 46e7b71..f5bebe1 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK   16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -371,6 +373,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4

Re: [Xen-devel] [GRUB2 PATCH v4 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

On Tue, Mar 15, 2016 at 07:46:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 15, 2016 at 04:26:00PM +0100, Daniel Kiper wrote:
> > Do not pass memory maps to image if it asked for EFI boot services.
>
> .. I would change this sentence a bit.
>
> If image requested EFI boot services then skip multiboot2 memory maps.
>
> > Main reason for not providing maps is because they will likely be
> > invalid. We do a few allocations after filling them, e.g. for relocator
> > needs. Usually we do not care as we would already finish boot services.
>
> s/would already finish/would have finished/ ?
>
> > If we keep boot services then it is easier to not provide maps. However,
>
> s/easier/safer?/
>
> > if image needs memory maps and they are not provided by bootloader then
> > it should get them itself just before ExitBootServices() call.
>
> s/them// ?
>
> That is making an assumption that the user of Multiboot2 + EFI will
> do this. Which is OK since only Xen is using it.. but is this
> inline with the spec? Can you ignore not providing this information?

AIUI, spec does not require that anything must be provided. Of course
on every platform GRUB2 should provide minimal set of system information
to properly boot loaded image. However, docs does not say which set make
sense or not. This is role of image to know what it requires to properly
run on a given platform. And I think that it make sense.

> That aside - why not sync the multiboot memory map with what
> the EFI one will be? Or is it too to complex to move the memory map
> creation to a later phase of the bootup?

IIRC, GRUB2 does some allocations after getting memory map and it is
quite complicated to change that.

> Wish there was some multboot memory map flag indicating 'STALE-CHECK-EFI'..

Why provide map which is invalid and must be verified with something else?
Let's ignore (do not provide) invalid data and use correct one without
any additional (unneeded) checks.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v4 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Tue, Mar 15, 2016 at 07:54:08PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 15, 2016 at 10:42:21PM +0100, Daniel Kiper wrote:
> > On Tue, Mar 15, 2016 at 05:30:20PM +0100, Vladimir 'phcoder' Serbinenko 
> > wrote:
> > > On Tuesday, March 15, 2016, Vladimir 'phcoder' Serbinenko 
> > > <phco...@gmail.com>
> > > wrote:
> > >
> > > >
> > > >> +   if (mld->relocatable)
> > > >> + err = grub_relocator_alloc_chunk_align
> > > >> (grub_multiboot_relocator, ,
> > > >> + mld->min_addr,
> > > >> mld->max_addr - phdr(i)->p_memsz,
> > > >> + phdr(i)->p_memsz,
> > > >> mld->align ? mld->align : 1,
> > > >> + mld->preference,
> > > >> mld->avoid_efi_boot_services);
> > > >> +   else
> > > >> + err = grub_relocator_alloc_chunk_addr
> > > >> (grub_multiboot_relocator,
> > > >> +,
> > > >> phdr(i)->p_paddr,
> > > >> +phdr(i)->p_memsz);
> > > >>
> > > > I believe this is faulty if you have more than one PHDR. You load every
> >
> > Argh... You are right!
> >
> > > > PHDR individually to essentially random address. Pieces have no 
> > > > reasonable
> > > > way to find each other. Moreover entry point calculation is also faulty.
> > > > Imagine sth like this:
> > > > PHDR 1M-2M
> > > > PHDR 2M-5M
> > > > Entry point 2.5M (in second PHDR)
> > > > then if first PHDR is loaded to 1M and second to 10M then base and link
> > > > addr are both 1M, so entry point will be calculated as 2.5M, which 
> > > > points
> > > > to no segment. I see 2 solutions:
> > > > 1) Look where entry falls in original layout, then adjust it in 
> > > > accordance
> > > > with where this phdr will be loaded. This requires least efforts. 
> > > > Finding
> > > > different PHDRs is still impossible but it will be possible in the 
> > > > future
> > > > with relocations.
> >
> > It looks that we should store somewhere and export to image via relevant 
> > tags
> > link addresses and load addresses. Hmmm... Maybe we should just provide load
> > addresses to image. Image can have link addresses in its data. And this
> > probably does not require huge changes.
> >
> > > > 2) Allocate a buffer of size highest - lowest and load everything into
> > > > this buffer keeping relative offsets. If we do this, then we need to
> > > > document if it's required for boorloader to behave this way or not. If 
> > > > it
> > > > is, we can in future provide a tag to say that image is fine with
> > > > rearrangement of PHDR, if it ever becomes relevant (I heavily doubt it).
> > > > I guess that xen is a single phdr image and so essentially any code will
> > > > work with it.
>
> Won't be in Xen 4.7.
> > > > This problem appears in couple of other places, I'll skip commenting on
> > > > them explicitly.
> > > >
> > > I take back the part "requires least effort" for solution 1. Solution 2 is
> > > probably simpler and less error-prone as developper doesn't control if
> > > binutils decode to put several phdrs.
> >
> > #2 looks promising but what if PHDR_1 is at 1 MiB - 2 MiB and PHDR_2 is at
> > 808 MiB - 809 MiB? Then we will allocate more than 800 MiB just for an
> > unusable hole. So, I think that we should go that way if solution #1
> > is too complicated.
>
> Daniel, my xSplice patches make the Xen have two ELF PHDRS: 1)the PT_LOAD
> and 2) PT_NOTE (which points to smack in the .text section) so you can try
> that as an example payload.
>
> (If you want to put your patches on top of mine:
> git://xenbits.xen.org/people/konradwilk/xen.git #xsplice.v4)

Thanks, but multiboot2 loads just PT_LOAD segments.

Daniel

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

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

[Daniel Kiper]

On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> Boris sent out the first HVMLite series of patches to add a new Xen guest type
> February 1, 2016 [0]. We've been talking off list with a few folks now over
> the prospect of instead of adding yet-another-boot-entry we instead fixate
> HVMLite to use the x86 EFI boot entry. There's a series of reasons to consider
> this, likewise there are reasons to question the effort required and if its
> really needed. We'd like some more public review of this proposal, and see if
> others can come up with other ideas, both in favor or against this proposal.
>
> This in particular is also a good time to get x86 Linux folks to chime on on
> the general design proposal of HVMLite design, given that outside of the boot
> entry discussion it would seem including myself that we didn't get the memo
> over the proposed architecture review [1]. At least on my behalf perhaps the
> only sticking thorns of the design was the new boot entry, which came to me
> as a surprise, and this thread addresses and the lack of addressing semantics
> for early boot (which we may seem to need to address; some of this is being
> addressing in parallels through other work). The HVMLite document talks about
> using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some 
> pending
> changes which should make it easy to integrate its use on HVMLite. Perhaps
> there are others that may have some other points they may want to raise now...
>
> A huge summary of the discussion over EFI boot option for HVMLite is now on a
> wiki [2], below I'll just provide the outline of the discussion. Consider 
> this a
> request for more public review, feel free to take any of the items below and
> elaborate on it as you see fit.
>
> Worth mentioning also is that this topic will be discussed at the 2016 Xen
> Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you can
> attend and this topic interests you, consider attending.

I hope that you will be there as one of the biggest proponents of EFI entry 
point.
If you does not it will be difficult or impossible to discuss this issue 
without you.
In the worst case I can raise this topic on behalf of you and then we should 
organize
phone call if possible (and accepted by others). However, to do that I must 
know your
plans in advance.

Daniel

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

[Xen-devel] [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move EFI platform specific C code to separate file
 (suggested by Vladimir 'phcoder' Serbinenko),
   - add some comments
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - reuse grub-core/lib/i386/relocator64.S code
 instead of creating separate assembly file
 (suggested by Vladimir 'phcoder' Serbinenko),
   - grub_multiboot_boot() cleanup
 (suggested by Vladimir 'phcoder' Serbinenko),
   - reuse multiboot_header_tag_entry_address struct instead
 of creating new one for EFI 64-bit entry point
 (suggested by Vladimir 'phcoder' Serbinenko).
---
 grub-core/Makefile.core.def  |1 +
 grub-core/lib/i386/relocator64.S |   11 +
 grub-core/lib/x86_64/efi/relocator.c |   76 ++
 grub-core/loader/multiboot.c |   51 ---
 grub-core/loader/multiboot_mbi2.c|   19 +++--
 include/grub/i386/multiboot.h|   11 +
 include/grub/i386/relocator.h|   21 ++
 include/multiboot2.h |1 +
 8 files changed, 182 insertions(+), 9 deletions(-)
 create mode 100644 grub-core/lib/x86_64/efi/relocator.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 58b4208..21ad0dd 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1531,6 +1531,7 @@ module = {
   i386_xen = lib/i386/xen/relocator.S;
   x86_64_xen = lib/x86_64/xen/relocator.S;
   xen = lib/i386/relocator_common_c.c;
+  x86_64_efi = lib/x86_64/efi/relocator.c;
 
   extra_dist = lib/i386/relocator_common.S;
   extra_dist = kern/powerpc/cache_flush.S;
diff --git a/grub-core/lib/i386/relocator64.S b/grub-core/lib/i386/relocator64.S
index e4648d8..75725cf 100644
--- a/grub-core/lib/i386/relocator64.S
+++ b/grub-core/lib/i386/relocator64.S
@@ -73,6 +73,14 @@ VARIABLE(grub_relocator64_rsp)
 
movq%rax, %rsp
 
+   /*
+* Here is grub_relocator64_efi_start() entry point.
+* Following code is shared between grub_relocator64_efi_start()
+* and grub_relocator64_start().
+*
+* Think twice before changing anything below!!!
+*/
+VARIABLE(grub_relocator64_efi_start)
/* mov imm64, %rax */
.byte   0x48
.byte   0xb8
@@ -120,6 +128,9 @@ LOCAL(jump_addr):
 VARIABLE(grub_relocator64_rip)
.quad   0
 
+   /* Here grub_relocator64_efi_start() ends. Ufff... */
+VARIABLE(grub_relocator64_efi_end)
+
 #ifndef __x86_64__
.p2align4
 LOCAL(gdt):
diff --git a/grub-core/lib/x86_64/efi/relocator.c 
b/grub-core/lib/x86_64/efi/relocator.c
new file mode 100644
index 000..c93d061
--- /dev/null
+++ b/grub-core/lib/x86_64/efi/relocator.c
@@ -0,0 +1,76 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *  Copyright (C) 2016  Oracle and/or its affiliates. All rights reserved.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+extern grub_uint64_t grub_relocator64_rax;
+extern grub_uint64_t grub_relocator64_rbx;
+extern grub_uint64_t grub_relocator64_rcx;
+extern grub_uint64_t grub_relocator64_rdx;
+extern grub_uint64_t grub_relocator64_rip;
+extern grub_uint64_t grub_relocator64_rsi;
+
+extern grub_uint8_t grub_relocator64_efi_start;
+extern grub_uint8_t grub_relocator64_efi_end;
+
+#define RELOCATOR_SIZEOF(x)(_relocator##x##_end - 
_relocator##x##_start)
+
+grub_err_t
+grub_relocator64_efi_boot (struct grub_relocator *rel,
+  struct grub_relocator64_efi_state state)
+{
+  grub_err_t err;
+  void *relst;
+  grub_relocator_chunk_t ch;
+
+  err = grub_relocator_alloc_chunk_ali

[Xen-devel] [GRUB2 PATCH v5 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,6 +755,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
   grub_fill_multiboot_mmap (tag);
@@ -776,6 +777,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_basic_meminfo *tag
= (struct multiboot_tag_basic_meminfo *) ptrorig;
@@ -886,21 +888,17 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
+if (!keep_bs)
+  {
tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
tag->size = sizeof (*tag) + efi_mmap_size;
 
-if (!keep_bs)
err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
 _desc_size, _desc_version);
-else
-  {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
-  }
+
if (err)
  return err;
+
tag->descr_size = efi_desc_size;
tag->descr_vers = efi_desc_version;
tag->size = sizeof (*tag) + efi_mmap_size;
@@ -908,6 +906,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
  / sizeof (grub_properly_aligned_t);
   }
+  }
 
   if (keep_bs)
 {
-- 
1.7.10.4


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

Re: [Xen-devel] [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Fri, Mar 25, 2016 at 12:28:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 18, 2016 at 06:00:23PM +0100, Daniel Kiper wrote:
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. 
> > Relocator
> > will set lower parts of %rax and %rbx accordingly to multiboot2 
> > specification.
> > On the other hand processor mode, just before jumping into loaded image, 
> > will
> > be set accordingly to Unified Extensible Firmware Interface Specification,
> > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> > loaded image will be able to use EFI boot services without any issues.
> >
> > Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
>
> .. with one modification:
> .. snip..
> > diff --git a/grub-core/lib/x86_64/efi/relocator.c 
> > b/grub-core/lib/x86_64/efi/relocator.c
> > new file mode 100644
> > index 000..c93d061
> > --- /dev/null
> > +++ b/grub-core/lib/x86_64/efi/relocator.c
> > +grub_err_t
> > +grub_relocator64_efi_boot (struct grub_relocator *rel,
> > +  struct grub_relocator64_efi_state state)
> > +{
> > +  grub_err_t err;
> > +  void *relst;
> > +  grub_relocator_chunk_t ch;
> > +
> > +  err = grub_relocator_alloc_chunk_align (rel, , 0,
> > + 0x4000 - RELOCATOR_SIZEOF 
> > (64_efi),
>   ^^ - why the 1GB?
>
> Could you give a bit details on it? Or preferrable have a comment right
> above saying what that value is used?

I took this from BSD loader. I assumed that if it uses this value then
it is safe to do the same here. However, it looks that we can safely use
"4 GiB - RELOCATOR_SIZEOF (64_efi)" too (probably higher value is also
good but I do not think we should go that way). If there are not
objections then I will repost fixed patch series next week.

Daniel

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

[Xen-devel] [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.

This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.

This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation 
provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it 
should
be build. At least to build proper test/example files.

So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.

This patch was tested with Xen image which uses that functionality. However, 
this Xen
feature is still under development and new patchset will be released in about 
3-4 weeks.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v5 - suggestions/fixes:
   - fix support for multi segment ELF files
 (suggested by Vladimir 'phcoder' Serbinenko),
   - add some input data checks,
   - add some comments.

v4 - suggestions/fixes:
   - pack grub_multiboot_load_elf() arguments into struct
 (suggested by Juergen Gross, Konrad Rzeszutek Wilk
 and Vladimir 'phcoder' Serbinenko),
   - fix entry point address calculation
 (suggested by Vladimir 'phcoder' Serbinenko),
   - fail if ELF file has relocs sections
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - reduce number of casts
 (suggested by Konrad Rzeszutek Wilk),
   - remove unneeded space at the end of line
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/i386/multiboot_mbi.c |   13 +++-
 grub-core/loader/multiboot.c  |   11 ++-
 grub-core/loader/multiboot_elfxx.c|  127 -
 grub-core/loader/multiboot_mbi2.c |  114 +++--
 include/grub/multiboot.h  |   22 +-
 include/multiboot2.h  |   24 +++
 6 files changed, 231 insertions(+), 80 deletions(-)

diff --git a/grub-core/loader/i386/multiboot_mbi.c 
b/grub-core/loader/i386/multiboot_mbi.c
index f60b702..fd7b41b 100644
--- a/grub-core/loader/i386/multiboot_mbi.c
+++ b/grub-core/loader/i386/multiboot_mbi.c
@@ -70,9 +70,18 @@ load_kernel (grub_file_t file, const char *filename,
 char *buffer, struct multiboot_header *header)
 {
   grub_err_t err;
+  mbi_load_data_t mld;
+
+  mld.file = file;
+  mld.filename = filename;
+  mld.buffer = buffer;
+  mld.mbi_ver = 1;
+  mld.relocatable = 0;
+  mld.avoid_efi_boot_services = 0;
+
   if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
 {
-  err = grub_multiboot_load_elf (file, filename, buffer);
+  err = grub_multiboot_load_elf ();
   if (err == GRUB_ERR_NONE) {
return GRUB_ERR_NONE;
   }
@@ -121,7 +130,7 @@ load_kernel (grub_file_t file, const char *filename,
   return GRUB_ERR_NONE;
 }
 
-  return grub_multiboot_load_elf (file, filename, buffer);
+  return grub_multiboot_load_elf ();
 }
 
 static struct multiboot_header *
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index 18038fd..bd9d

[Xen-devel] [GRUB2 PATCH v5 3/4 - FOR COMMIT] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   71 ++---
 1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,12 +755,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
-  {
-struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
-grub_fill_multiboot_mmap (tag);
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
-  }
+  if (!keep_bs)
+{
+  struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
+  grub_fill_multiboot_mmap (tag);
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct multiboot_tag_elf_sections *tag
@@ -776,18 +777,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
-  {
-struct multiboot_tag_basic_meminfo *tag
-  = (struct multiboot_tag_basic_meminfo *) ptrorig;
-tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
-tag->size = sizeof (struct multiboot_tag_basic_meminfo); 
+  if (!keep_bs)
+{
+  struct multiboot_tag_basic_meminfo *tag
+   = (struct multiboot_tag_basic_meminfo *) ptrorig;
+  tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
+  tag->size = sizeof (struct multiboot_tag_basic_meminfo);
 
-/* Convert from bytes to kilobytes.  */
-tag->mem_lower = grub_mmap_get_lower () / 1024;
-tag->mem_upper = grub_mmap_get_upper () / 1024;
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
-  }
+  /* Convert from bytes to kilobytes.  */
+  tag->mem_lower = grub_mmap_get_lower () / 1024;
+  tag->mem_upper = grub_mmap_get_upper () / 1024;
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct grub_net_network_level_interface *net;
@@ -886,27 +888,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
-tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
 if (!keep_bs)
-  err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, NULL,
-  _desc_size, _desc_version);
-else
   {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
+_desc_size, _desc_version);
+
+   if (err)
+ return err;
+
+   tag->descr_size = efi_desc_size;
+   tag->descr_vers = efi_desc_version;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
   }
-if (err)
-  return err;
-tag->descr_size = efi_desc_size;
-tag->descr_vers = efi_desc_version;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
   }
 
   if (keep_bs)
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v4 10/11] xen: modify page table construction

[Daniel Kiper]

On Wed, Mar 02, 2016 at 04:43:07PM +0100, Juergen Gross wrote:
> On 02/03/16 10:12, Daniel Kiper wrote:
> > On Mon, Feb 29, 2016 at 01:19:27PM +0100, Juergen Gross wrote:
> >> On 29/02/16 10:13, Juergen Gross wrote:
> >>> On 25/02/16 19:33, Andrei Borzenkov wrote:
> >>>> 22.02.2016 16:14, Juergen Gross пишет:
> >>>>> On 22/02/16 13:48, Daniel Kiper wrote:
> >>>>>> On Mon, Feb 22, 2016 at 01:30:30PM +0100, Juergen Gross wrote:
> >>>>>>> On 22/02/16 13:18, Daniel Kiper wrote:
> >>>>>>>> On Mon, Feb 22, 2016 at 10:29:04AM +0100, Juergen Gross wrote:
> >>>>>>>>> On 22/02/16 10:17, Daniel Kiper wrote:
> >>>>>>>>>> On Mon, Feb 22, 2016 at 07:03:18AM +0100, Juergen Gross wrote:
> >>>>>>>>>>> diff --git a/grub-core/lib/xen/relocator.c 
> >>>>>>>>>>> b/grub-core/lib/xen/relocator.c
> >>>>>>>>>>> index 8f427d3..a05b253 100644
> >>>>>>>>>>> --- a/grub-core/lib/xen/relocator.c
> >>>>>>>>>>> +++ b/grub-core/lib/xen/relocator.c
> >>>>>>>>>>> @@ -29,6 +29,11 @@
> >>>>>>>>>>>
> >>>>>>>>>>>  typedef grub_addr_t grub_xen_reg_t;
> >>>>>>>>>>>
> >>>>>>>>>>> +struct grub_relocator_xen_paging_area {
> >>>>>>>>>>> +  grub_xen_reg_t start;
> >>>>>>>>>>> +  grub_xen_reg_t size;
> >>>>>>>>>>> +};
> >>>>>>>>>>> +
> >>>>>>>>>>
> >>>>>>>>>> ... this should have GRUB_PACKED because compiler may
> >>>>>>>>>> add padding to align size member.
> >>>>>>>>>
> >>>>>>>>> Why would the compiler add padding to a structure containing two 
> >>>>>>>>> items
> >>>>>>>>> of the same type? I don't think the C standard would allow this.
> >>>>>>>>>
> >>>>>>>>> grub_xen_reg_t is either unsigned (32 bit) or unsigned long (64 
> >>>>>>>>> bit).
> >>>>>>>>> There is no way this could require any padding.
> >>>>>>>>
> >>>>>>>> You are right but we should add this here just in case.
> >>>>>>>
> >>>>>>> Sorry, I don't think this makes any sense. The C standard is very 
> >>>>>>> clear
> >>>>>>> in this case: a type requiring a special alignment has always a length
> >>>>>>> being a multiple of that alignment. Otherwise arrays wouldn't work.
> >>>>>>
> >>>>>> Sorry, I am not sure what do you mean by that.
> >>>>>
> >>>>> The size of any C type (no matter whether it is an integral type like
> >>>>> "int" or a structure) has always the same alignment restriction as the
> >>>>> type itself. So a type requiring 8 byte alignment will always have a
> >>>>> size of a multiple of 8 bytes. This is mandatory for arrays to work, as
> >>>>> otherwise either the elements wouldn't be placed consecutively in memory
> >>>>> or the alignment restrictions wouldn't be obeyed for all elements.
> >>>>>
> >>>>
> >>>> I too not follow how it is relevant to this case. We talk about internal
> >>>> padding between structure members, not between array elements.
> >>>>
> >>>>> For our case it means that two structure elements of the same type will
> >>>>> never require a padding between them, thus the annotation with "packed"
> >>>>> can't serve any purpose.
> >>>>>
> >>>>
> >>>> Well, I am not aware of any requirement. Compiler may add arbitrary
> >>>> padding between structure elements; it is only prohibited to add padding
> >>>> at the beginning. Sure, it would be unusual, but never say "never" ...
> >>>> also should Xen ever be ported to architecture where types are not
> >>>> self-aligned it will become an issue.
> >>>
> >>> So you

[Xen-devel] [GRUB2 PATCH v3 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - mbi EFI related stuff size calculation
 should depend on target architecture
 (suggested by Konrad Rzeszutek Wilk),
   - use plain type instead of pointer
 dereference as sizeof() argument
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/multiboot_mbi2.c |   50 ++---
 include/multiboot2.h  |   16 
 2 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index a3dca90..7591edc 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char *filename)
  case MULTIBOOT_TAG_TYPE_NETWORK:
  case MULTIBOOT_TAG_TYPE_EFI_MMAP:
  case MULTIBOOT_TAG_TYPE_EFI_BS:
+ case MULTIBOOT_TAG_TYPE_EFI32_IH:
+ case MULTIBOOT_TAG_TYPE_EFI64_IH:
break;
 
  default:
@@ -407,16 +409,22 @@ grub_multiboot_get_mbi_size (void)
 + grub_get_multiboot_mmap_count ()
 * sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), MULTIBOOT_TAG_ALIGN)
+#ifdef GRUB_MACHINE_EFI
+#ifdef __i386__
 + ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
+#endif
+#ifdef __x86_64__
 + ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
+#endif
++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
+#endif
 + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
 + acpiv2_size ()
 + net_size ()
-#ifdef GRUB_MACHINE_EFI
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
-   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
-#endif
 + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
 + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
 }
@@ -907,11 +915,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 
   if (keep_bs)
 {
-  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
-  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
-  tag->size = sizeof (struct multiboot_tag);
-  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
+  {
+   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
+   tag->size = sizeof (struct multiboot_tag);
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+
+#ifdef __i386__
+  {
+   struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
+   tag->size = sizeof (struct multiboot_tag_efi32_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
+
+#ifdef __x86_64__
+  {
+   struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
+   tag->size = sizeof (struct multiboot_tag_efi64_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
 }
 #endif
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index d96aa40..36a174f 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK   16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -371,6 +373,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4

[Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.

If idea is accepted I will prepare grub_relocator32_efi relocator too.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - reuse grub-core/lib/i386/relocator64.S code
 instead of creating separate assembly file
 (suggested by Vladimir 'phcoder' Serbinenko),
   - grub_multiboot_boot() cleanup
 (suggested by Vladimir 'phcoder' Serbinenko),
   - reuse multiboot_header_tag_entry_address struct instead
 of creating new one for EFI 64-bit entry point
 (suggested by Vladimir 'phcoder' Serbinenko).
---
 grub-core/lib/i386/relocator.c|   48 ++
 grub-core/lib/i386/relocator64.S  |3 +++
 grub-core/loader/multiboot.c  |   51 +
 grub-core/loader/multiboot_mbi2.c |   19 +++---
 include/grub/i386/multiboot.h |   11 
 include/grub/i386/relocator.h |   21 +++
 include/multiboot2.h  |1 +
 7 files changed, 145 insertions(+), 9 deletions(-)

diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
index 71dd4f0..2b0c260 100644
--- a/grub-core/lib/i386/relocator.c
+++ b/grub-core/lib/i386/relocator.c
@@ -69,6 +69,13 @@ extern grub_uint64_t grub_relocator64_rsi;
 extern grub_addr_t grub_relocator64_cr3;
 extern struct grub_i386_idt grub_relocator16_idt;
 
+#ifdef GRUB_MACHINE_EFI
+#ifdef __x86_64__
+extern grub_uint8_t grub_relocator64_efi_start;
+extern grub_uint8_t grub_relocator64_efi_end;
+#endif
+#endif
+
 #define RELOCATOR_SIZEOF(x)(_relocator##x##_end - 
_relocator##x##_start)
 
 grub_err_t
@@ -214,3 +221,44 @@ grub_relocator64_boot (struct grub_relocator *rel,
   /* Not reached.  */
   return GRUB_ERR_NONE;
 }
+
+#ifdef GRUB_MACHINE_EFI
+#ifdef __x86_64__
+grub_err_t
+grub_relocator64_efi_boot (struct grub_relocator *rel,
+  struct grub_relocator64_efi_state state)
+{
+  grub_err_t err;
+  void *relst;
+  grub_relocator_chunk_t ch;
+
+  err = grub_relocator_alloc_chunk_align (rel, , 0,
+ 0x4000 - RELOCATOR_SIZEOF 
(64_efi),
+ RELOCATOR_SIZEOF (64_efi), 16,
+ GRUB_RELOCATOR_PREFERENCE_NONE, 1);
+  if (err)
+return err;
+
+  /* Do not touch %rsp! It points to EFI created stack. */
+  grub_relocator64_rax = state.rax;
+  grub_relocator64_rbx = state.rbx;
+  grub_relocator64_rcx = state.rcx;
+  grub_relocator64_rdx = state.rdx;
+  grub_relocator64_rip = state.rip;
+  grub_relocator64_rsi = state.rsi;
+
+  grub_memmove (get_virtual_current_address (ch), _relocator64_efi_start,
+   RELOCATOR_SIZEOF (64_efi));
+
+  err = grub_relocator_prepare_relocs (rel, get_physical_target_address (ch),
+  , NULL);
+  if (err)
+return err;
+
+  ((void (*) (void)) relst) ();
+
+  /* Not reached.  */
+  return GRUB_ERR_NONE;
+}
+#endif
+#endif
diff --git a/grub-core/lib/i386/relocator64.S b/grub-core/lib/i386/relocator64.S
index e4648d8..7a06b16 100644
--- a/grub-core/lib/i386/relocator64.S
+++ b/grub-core/lib/i386/relocator64.S
@@ -73,6 +73,7 @@ VARIABLE(grub_relocator64_rsp)
 
movq%rax, %rsp
 
+VARIABLE(grub_relocator64_efi_start)
/* mov imm64, %rax */
.byte   0x48
.byte   0xb8
@@ -120,6 +121,8 @@ LOCAL(jump_addr):
 VARIABLE(grub_relocator64_rip)
.quad   0
 
+VARIABLE(grub_relocator64_efi_end)
+
 #ifndef __x86_64__
.p2align4
 LOCAL(gdt):
diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
index 73aa0aa..18038fd 100644
--- a/grub-core/loader/multiboot.c
+++ b/grub-core/loader/multiboot.c
@@ -118,6 +118,48 @@ grub_multiboot_set_video_mode (void)
   return err;
 }
 
+#ifdef GRUB_MACHINE_EFI
+#ifdef __x86_64__
+#define grub_relocator_efi_bootgrub_relocator64_efi_boot
+#define grub_relocator_efi_state   grub_relocator64_efi_state
+#endif
+#endif
+
+#ifdef grub_relocator_efi_boot
+static void
+efi_boot (struct grub_relocator *rel,
+ grub_uint32_t target)
+{
+  struct grub_relocator_efi_state state_efi = MULTIBOOT_EFI_INITIAL_STATE;
+
+  state_efi.MULTIBOOT_EFI_ENTRY_REGISTER = grub_multiboot_payload_eip;
+  state_efi.MULTIBOOT_EFI_MBI_REGISTER = target;
+
+  grub_relocator_efi_boot (rel, state_efi);
+}
+#else
+#define grub_efi_is_finished   1
+static void
+efi_boot (struct grub_relocator *rel __attri

[Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to simply set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.

This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary. Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static
and dynamic knowledge provided by boot loader.

This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation 
provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it 
should
be build. At least to build proper test/example files.

As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF files.
Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie 
option.
However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC, GNU_EH_FRAME
program headers) and it could be quite difficult to drop them (Hmmm... Is it
possible to build it properly with custom ld script?). So, I have checked 
ET_EXEC
file type. Sadly in this case linker by default resolves all local symbol 
relocations
and removes relocation related sections. Fortunately it is possible to leave 
them
as is with simple -q/--emit-relocs ld option. However, output file is quite 
fragile
and any operation on it should be done with great care (e.g. strip should be 
called
with --strip-unneeded option). So, this solution is not perfect too. It means 
that
maybe we should look for better solution. However, I think that we should not 
use
any custom tools and focus on functionalities provided by compiler and binutils.
In this context ld scripts looks quite promising but maybe you have better 
solutions.
So, what do you think about that?

This patch was tested with Xen image which uses that functionality. However, 
this Xen
feature is still under development and new patchset will be released in about 
3-4 weeks.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - reduce number of casts
 (suggested by Konrad Rzeszutek Wilk),
   - remove unneeded space at the end of line
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/i386/multiboot_mbi.c |6 ++-
 grub-core/loader/multiboot.c  |   12 --
 grub-core/loader/multiboot_elfxx.c|   28 ++
 grub-core/loader/multiboot_mbi2.c |   65 ++---
 include/grub/multiboot.h  |4 +-
 include/multiboot2.h  |   24 
 6 files changed, 120 insertions(+), 19 deletions(-)

diff --git a/grub-core/loader/i386/multiboot_mbi.c 
b/grub-core/loader/i386/multiboot_mbi.c
index f60b702..4fc83ed 100644
--- a/grub-core/loader/i386/multiboot_mbi.c
+++ b/grub-core/loader/i386/multiboot_mbi.c
@@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
   grub_err_t err;
   if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
 {
-  err = grub_multiboot_load_elf (file, filename, buffer);
+  err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
+GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
   if (err == GRUB_ERR_NONE) {
return GRUB_ERR_NONE;
   }
@@ -121,7 +122,8 @@ load_kernel (grub_file_t file, const char *filename,
   return GRUB_ERR_NONE;
 }
 
-  return grub_multiboot_load_elf (file, filename, buffer);

[Xen-devel] [GRUB2 PATCH v3 3/4] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

Do not pass memory maps to image if it asked for EFI boot services.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would already finish boot services.
If we keep boot services then it is easier to not provide maps. However,
if image needs memory maps and they are not provided by bootloader then
it should get them itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   71 ++---
 1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 7591edc..ce68f48 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -759,12 +759,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
-  {
-struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
-grub_fill_multiboot_mmap (tag);
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
-  }
+  if (!keep_bs)
+{
+  struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
+  grub_fill_multiboot_mmap (tag);
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct multiboot_tag_elf_sections *tag
@@ -780,18 +781,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
-  {
-struct multiboot_tag_basic_meminfo *tag
-  = (struct multiboot_tag_basic_meminfo *) ptrorig;
-tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
-tag->size = sizeof (struct multiboot_tag_basic_meminfo); 
+  if (!keep_bs)
+{
+  struct multiboot_tag_basic_meminfo *tag
+   = (struct multiboot_tag_basic_meminfo *) ptrorig;
+  tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
+  tag->size = sizeof (struct multiboot_tag_basic_meminfo);
 
-/* Convert from bytes to kilobytes.  */
-tag->mem_lower = grub_mmap_get_lower () / 1024;
-tag->mem_upper = grub_mmap_get_upper () / 1024;
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
-  }
+  /* Convert from bytes to kilobytes.  */
+  tag->mem_lower = grub_mmap_get_lower () / 1024;
+  tag->mem_upper = grub_mmap_get_upper () / 1024;
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct grub_net_network_level_interface *net;
@@ -890,27 +892,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
-tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
 if (!keep_bs)
-  err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, NULL,
-  _desc_size, _desc_version);
-else
   {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
+_desc_size, _desc_version);
+
+   if (err)
+ return err;
+
+   tag->descr_size = efi_desc_size;
+   tag->descr_vers = efi_desc_version;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
   }
-if (err)
-  return err;
-tag->descr_size = efi_desc_size;
-tag->descr_vers = efi_desc_version;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
   }
 
   if (keep_bs)
-- 
1.7.10.4


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

[Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

Hi,

This patch series:
  - enables EFI boot services usage in loaded images
by multiboot2 protocol,
  - add support for multiboot2 protocol compatible
relocatable images.

Earlier versions of this patch series are extensively tested
and used internally at least in Oracle. It should be mentioned
that this release does not change any functionality introduced
by earlier releases. It just takes into account comments posted
by various people.

Hmmm... Ugh... Cough... Is it possible to get this stuff
into 2.02 train?

Daniel

 grub-core/lib/i386/relocator.c|   48 +++
 grub-core/lib/i386/relocator64.S  |3 ++
 grub-core/loader/i386/multiboot_mbi.c |6 ++-
 grub-core/loader/multiboot.c  |   63 
 grub-core/loader/multiboot_elfxx.c|   28 ---
 grub-core/loader/multiboot_mbi2.c |  205 
+-
 include/grub/i386/multiboot.h |   11 +
 include/grub/i386/relocator.h |   21 
 include/grub/multiboot.h  |4 +-
 include/multiboot2.h  |   41 
 10 files changed, 357 insertions(+), 73 deletions(-)

Daniel Kiper (4):
  i386/relocator: Add grub_relocator64_efi relocator
  multiboot2: Add tags used to pass ImageHandle to loaded image
  multiboot2: Do not pass memory maps to image if EFI boot services are 
enabled
  multiboot2: Add support for relocatable images


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

Re: [Xen-devel] [PATCH v4 10/11] xen: modify page table construction

[Daniel Kiper]

On Mon, Feb 29, 2016 at 01:19:27PM +0100, Juergen Gross wrote:
> On 29/02/16 10:13, Juergen Gross wrote:
> > On 25/02/16 19:33, Andrei Borzenkov wrote:
> >> 22.02.2016 16:14, Juergen Gross пишет:
> >>> On 22/02/16 13:48, Daniel Kiper wrote:
> >>>> On Mon, Feb 22, 2016 at 01:30:30PM +0100, Juergen Gross wrote:
> >>>>> On 22/02/16 13:18, Daniel Kiper wrote:
> >>>>>> On Mon, Feb 22, 2016 at 10:29:04AM +0100, Juergen Gross wrote:
> >>>>>>> On 22/02/16 10:17, Daniel Kiper wrote:
> >>>>>>>> On Mon, Feb 22, 2016 at 07:03:18AM +0100, Juergen Gross wrote:
> >>>>>>>>> diff --git a/grub-core/lib/xen/relocator.c 
> >>>>>>>>> b/grub-core/lib/xen/relocator.c
> >>>>>>>>> index 8f427d3..a05b253 100644
> >>>>>>>>> --- a/grub-core/lib/xen/relocator.c
> >>>>>>>>> +++ b/grub-core/lib/xen/relocator.c
> >>>>>>>>> @@ -29,6 +29,11 @@
> >>>>>>>>>
> >>>>>>>>>  typedef grub_addr_t grub_xen_reg_t;
> >>>>>>>>>
> >>>>>>>>> +struct grub_relocator_xen_paging_area {
> >>>>>>>>> +  grub_xen_reg_t start;
> >>>>>>>>> +  grub_xen_reg_t size;
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>
> >>>>>>>> ... this should have GRUB_PACKED because compiler may
> >>>>>>>> add padding to align size member.
> >>>>>>>
> >>>>>>> Why would the compiler add padding to a structure containing two items
> >>>>>>> of the same type? I don't think the C standard would allow this.
> >>>>>>>
> >>>>>>> grub_xen_reg_t is either unsigned (32 bit) or unsigned long (64 bit).
> >>>>>>> There is no way this could require any padding.
> >>>>>>
> >>>>>> You are right but we should add this here just in case.
> >>>>>
> >>>>> Sorry, I don't think this makes any sense. The C standard is very clear
> >>>>> in this case: a type requiring a special alignment has always a length
> >>>>> being a multiple of that alignment. Otherwise arrays wouldn't work.
> >>>>
> >>>> Sorry, I am not sure what do you mean by that.
> >>>
> >>> The size of any C type (no matter whether it is an integral type like
> >>> "int" or a structure) has always the same alignment restriction as the
> >>> type itself. So a type requiring 8 byte alignment will always have a
> >>> size of a multiple of 8 bytes. This is mandatory for arrays to work, as
> >>> otherwise either the elements wouldn't be placed consecutively in memory
> >>> or the alignment restrictions wouldn't be obeyed for all elements.
> >>>
> >>
> >> I too not follow how it is relevant to this case. We talk about internal
> >> padding between structure members, not between array elements.
> >>
> >>> For our case it means that two structure elements of the same type will
> >>> never require a padding between them, thus the annotation with "packed"
> >>> can't serve any purpose.
> >>>
> >>
> >> Well, I am not aware of any requirement. Compiler may add arbitrary
> >> padding between structure elements; it is only prohibited to add padding
> >> at the beginning. Sure, it would be unusual, but never say "never" ...
> >> also should Xen ever be ported to architecture where types are not
> >> self-aligned it will become an issue.
> >
> > So you are telling me that _all_ interfaces between e.g. Linux, grub2,
> > Xen and all wire protocols not attributed with "packed" are just wrong?
> >
> > Sorry, I don't think this is true.
>
> Okay, just found a reference: The x86 ABI states:
>
> Aggregates and Unions
> -
> Structures and unions assume the alignment of their most strictly
> aligned component. Each member is assigned to the lowest available
> offset with the appropriate alignment. The size of any object is always
> a multiple of the object‘s alignment.
>
> I don't think any x86 C-compiler will violate the x86 ABI.

You just cited only part of paragraph. Here is full paragraph:

[...]

Aggregate

Re: [Xen-devel] [PATCH v6 09/11] xen: add capability to load initrd outside of initial mapping

[Daniel Kiper]

On Tue, Mar 01, 2016 at 08:55:09AM +0100, Juergen Gross wrote:
> Modern pvops linux kernels support an initrd not covered by the initial
> mapping. This capability is flagged by an elf-note.
>
> In case the elf-note is set by the kernel don't place the initrd into
> the initial mapping. This will allow to load larger initrds and/or
> support domains with larger memory, as the initial mapping is limited
> to 2GB and it is containing the p2m list.
>
> Signed-off-by: Juergen Gross <jgr...@suse.com>
> Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
> ---
> V6: rename grub_xen_alloc_final() to grub_xen_alloc_boot_data()
> V5: let call grub_xen_alloc_final() all subfunctions unconditionally
> and let them decide whether they need to do anything
> V4: rename grub_xen_alloc_end() to grub_xen_alloc_final()
> ---
>  grub-core/loader/i386/xen.c| 66 
> ++
>  grub-core/loader/i386/xen_fileXX.c |  3 ++
>  include/grub/xen_file.h|  1 +
>  3 files changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> index 2e12763..989a60b 100644
> --- a/grub-core/loader/i386/xen.c
> +++ b/grub-core/loader/i386/xen.c
> @@ -228,6 +228,9 @@ grub_xen_p2m_alloc (void)
>grub_size_t p2msize;
>grub_err_t err;
>
> +  if (xen_state.virt_mfn_list)
> +return GRUB_ERR_NONE;
> +
>xen_state.state.mfn_list = xen_state.max_addr;
>xen_state.next_start.mfn_list =
>  xen_state.max_addr + xen_state.xen_inf.virt_base;
> @@ -250,6 +253,9 @@ grub_xen_special_alloc (void)
>grub_relocator_chunk_t ch;
>grub_err_t err;
>
> +  if (xen_state.virt_start_info)
> +return GRUB_ERR_NONE;
> +
>err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
>xen_state.max_addr,
>sizeof (xen_state.next_start));
> @@ -281,6 +287,9 @@ grub_xen_pt_alloc (void)
>grub_uint64_t nr_info_pages;
>grub_uint64_t nr_pages, nr_pt_pages, nr_need_pages;
>
> +  if (xen_state.virt_pgtable)
> +return GRUB_ERR_NONE;
> +
>xen_state.next_start.pt_base =
>  xen_state.max_addr + xen_state.xen_inf.virt_base;
>xen_state.state.paging_start = xen_state.max_addr >> PAGE_SHIFT;
> @@ -319,6 +328,25 @@ grub_xen_pt_alloc (void)
>return GRUB_ERR_NONE;
>  }
>
> +/* Allocate all not yet allocated areas mapped by initial page tables. */
> +static grub_err_t
> +grub_xen_alloc_boot_data (void)
> +{
> +  grub_err_t err;
> +
> +  err = grub_xen_p2m_alloc ();
> +  if (err)
> +return err;
> +  err = grub_xen_special_alloc ();
> +  if (err)
> +return err;
> +  err = grub_xen_pt_alloc ();
> +  if (err)
> +return err;
> +
> +  return GRUB_ERR_NONE;
> +}
> +
>  static grub_err_t
>  grub_xen_boot (void)
>  {
> @@ -330,13 +358,7 @@ grub_xen_boot (void)
>if (grub_xen_n_allocated_shared_pages)
>  return grub_error (GRUB_ERR_BUG, "active grants");
>
> -  err = grub_xen_p2m_alloc ();
> -  if (err)
> -return err;
> -  err = grub_xen_special_alloc ();
> -  if (err)
> -return err;
> -  err = grub_xen_pt_alloc ();
> +  err = grub_xen_alloc_boot_data ();
>if (err)
>  return err;
>
> @@ -610,6 +632,13 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ 
> ((unused)),
>goto fail;
>  }
>
> +  if (xen_state.xen_inf.unmapped_initrd)
> +{
> +  err = grub_xen_alloc_boot_data ();
> +  if (err)
> + goto fail;
> +}
> +
>if (grub_initrd_init (argc, argv, _ctx))
>  goto fail;
>
> @@ -627,14 +656,24 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ 
> ((unused)),
>   goto fail;
>  }
>
> -  xen_state.next_start.mod_start =
> -xen_state.max_addr + xen_state.xen_inf.virt_base;
> -  xen_state.next_start.mod_len = size;

You forgot about leaving this as is...

> -
> -  xen_state.max_addr = ALIGN_UP (xen_state.max_addr + size, PAGE_SIZE);
> +  if (xen_state.xen_inf.unmapped_initrd)
> +{
> +  xen_state.next_start.flags |= SIF_MOD_START_PFN;
> +  xen_state.next_start.mod_start = xen_state.max_addr >> PAGE_SHIFT;
> +  xen_state.next_start.mod_len = size;

Then you do not need this...

> +}
> +  else
> +{
> +  xen_state.next_start.mod_start =
> + xen_state.max_addr + xen_state.xen_inf.virt_base;
> +  xen_state.next_start.mod_len = size;

... nor this...

> +}

... and even this curly brackets...

Daniel

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

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

[Daniel Kiper]

On Thu, Mar 03, 2016 at 10:38:05AM +0100, Juergen Gross wrote:
> The Xen hypervisor supports starting a dom0 with large memory (up to
> the TB range) by not including the initrd and p2m list in the initial
> kernel mapping. Especially the p2m list can grow larger than the
> available virtual space in the initial mapping.
>
> The started kernel is indicating the support of each feature via
> elf notes.
>
> This series enables grub-xen to do the same as the hypervisor.

Looks good to me. Thanks for doing the work!

I think that maybe it is worth trying to include this
in 2.02 release. If you wish please ask about that
in this http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00047.html
thread. CC me if you do that.

Daniel

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

Re: [Xen-devel] [PATCH v6 09/11] xen: add capability to load initrd outside of initial mapping

[Daniel Kiper]

On Wed, Mar 02, 2016 at 09:14:23AM +0100, Juergen Gross wrote:
> On 02/03/16 08:56, Daniel Kiper wrote:
> > On Tue, Mar 01, 2016 at 08:55:09AM +0100, Juergen Gross wrote:
> >> Modern pvops linux kernels support an initrd not covered by the initial
> >> mapping. This capability is flagged by an elf-note.
> >>
> >> In case the elf-note is set by the kernel don't place the initrd into
> >> the initial mapping. This will allow to load larger initrds and/or
> >> support domains with larger memory, as the initial mapping is limited
> >> to 2GB and it is containing the p2m list.
> >>
> >> Signed-off-by: Juergen Gross <jgr...@suse.com>
> >> Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
> >> ---
> >> V6: rename grub_xen_alloc_final() to grub_xen_alloc_boot_data()
> >> V5: let call grub_xen_alloc_final() all subfunctions unconditionally
> >> and let them decide whether they need to do anything
> >> V4: rename grub_xen_alloc_end() to grub_xen_alloc_final()
> >> ---
> >>  grub-core/loader/i386/xen.c| 66 
> >> ++
> >>  grub-core/loader/i386/xen_fileXX.c |  3 ++
> >>  include/grub/xen_file.h|  1 +
> >>  3 files changed, 57 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> >> index 2e12763..989a60b 100644
> >> --- a/grub-core/loader/i386/xen.c
> >> +++ b/grub-core/loader/i386/xen.c
> >> @@ -228,6 +228,9 @@ grub_xen_p2m_alloc (void)
> >>grub_size_t p2msize;
> >>grub_err_t err;
> >>
> >> +  if (xen_state.virt_mfn_list)
> >> +return GRUB_ERR_NONE;
> >> +
> >>xen_state.state.mfn_list = xen_state.max_addr;
> >>xen_state.next_start.mfn_list =
> >>  xen_state.max_addr + xen_state.xen_inf.virt_base;
> >> @@ -250,6 +253,9 @@ grub_xen_special_alloc (void)
> >>grub_relocator_chunk_t ch;
> >>grub_err_t err;
> >>
> >> +  if (xen_state.virt_start_info)
> >> +return GRUB_ERR_NONE;
> >> +
> >>err = grub_relocator_alloc_chunk_addr (xen_state.relocator, ,
> >> xen_state.max_addr,
> >> sizeof (xen_state.next_start));
> >> @@ -281,6 +287,9 @@ grub_xen_pt_alloc (void)
> >>grub_uint64_t nr_info_pages;
> >>grub_uint64_t nr_pages, nr_pt_pages, nr_need_pages;
> >>
> >> +  if (xen_state.virt_pgtable)
> >> +return GRUB_ERR_NONE;
> >> +
> >>xen_state.next_start.pt_base =
> >>  xen_state.max_addr + xen_state.xen_inf.virt_base;
> >>xen_state.state.paging_start = xen_state.max_addr >> PAGE_SHIFT;
> >> @@ -319,6 +328,25 @@ grub_xen_pt_alloc (void)
> >>return GRUB_ERR_NONE;
> >>  }
> >>
> >> +/* Allocate all not yet allocated areas mapped by initial page tables. */
> >> +static grub_err_t
> >> +grub_xen_alloc_boot_data (void)
> >> +{
> >> +  grub_err_t err;
> >> +
> >> +  err = grub_xen_p2m_alloc ();
> >> +  if (err)
> >> +return err;
> >> +  err = grub_xen_special_alloc ();
> >> +  if (err)
> >> +return err;
> >> +  err = grub_xen_pt_alloc ();
> >> +  if (err)
> >> +return err;
> >> +
> >> +  return GRUB_ERR_NONE;
> >> +}
> >> +
> >>  static grub_err_t
> >>  grub_xen_boot (void)
> >>  {
> >> @@ -330,13 +358,7 @@ grub_xen_boot (void)
> >>if (grub_xen_n_allocated_shared_pages)
> >>  return grub_error (GRUB_ERR_BUG, "active grants");
> >>
> >> -  err = grub_xen_p2m_alloc ();
> >> -  if (err)
> >> -return err;
> >> -  err = grub_xen_special_alloc ();
> >> -  if (err)
> >> -return err;
> >> -  err = grub_xen_pt_alloc ();
> >> +  err = grub_xen_alloc_boot_data ();
> >>if (err)
> >>  return err;
> >>
> >> @@ -610,6 +632,13 @@ grub_cmd_initrd (grub_command_t cmd __attribute__ 
> >> ((unused)),
> >>goto fail;
> >>  }
> >>
> >> +  if (xen_state.xen_inf.unmapped_initrd)
> >> +{
> >> +  err = grub_xen_alloc_boot_data ();
> >> +  if (err)
> >> +  goto fail;
> >> +}
> >> +
> >>if (grub_initrd_init (argc, argv, _ctx))
> &g

[Xen-devel] [GRUB2 PATCH v6 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

Currently multiboot2 protocol loads image exactly at address specified in
ELF or multiboot2 header. This solution works quite well on legacy BIOS
platforms. It is possible because memory regions are placed at predictable
addresses (though I was not able to find any spec which says that it is
strong requirement, so, it looks that it is just a goodwill of hardware
designers). However, EFI platforms are more volatile. Even if required
memory regions live at specific addresses then they are sometimes simply
not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
OVMF). This means that you are not able to just set up final image
destination on build time. You have to provide method to relocate image
contents to real load address which is usually different than load address
specified in ELF and multiboot2 headers.

This patch provides all needed machinery to do self relocation in image code.
First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
align (required image alignment), preference (it says which memory regions are
preferred by image, e.g. none, low, high) from multiboot_header_tag_relocatable
header tag contained in binary (at this stage load addresses from multiboot2
and/or ELF headers are ignored). Later loader tries to fulfill request (not only
that one) and if it succeeds then it informs image about real load address via
multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. Starting
from now executable must cope with relocations itself using whole static and
dynamic knowledge provided by boot loader.

This patch does not provide functionality which could do relocations using
ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and Vladimir
'phcoder' Serbinenko to investigate that thing. It looks that relevant machinery
could be added to existing code (including this patch) without huge effort.
Additionally, ELF relocation could live in parallel with self relocation 
provided
by this patch. However, during research I realized that first of all we should
establish the details how ELF relocatable image should look like and how it 
should
be build. At least to build proper test/example files.

So, this patch just provides support for self relocatable images. If ELF file
with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
such files will be added later.

This patch was tested with Xen image which uses that functionality. However, 
this Xen
feature is still under development and new patchset will be released in about 
2-3 weeks.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v6 - suggestions/fixes:
   - fix error message in grub_multiboot_load_elf()
 (suggested by Konrad Rzeszutek Wilk),
   - improve debug messages.

v5 - suggestions/fixes:
   - fix support for multi segment ELF files
 (suggested by Vladimir 'phcoder' Serbinenko),
   - add some input data checks,
   - add some comments.

v4 - suggestions/fixes:
   - pack grub_multiboot_load_elf() arguments into struct
 (suggested by Juergen Gross, Konrad Rzeszutek Wilk
 and Vladimir 'phcoder' Serbinenko),
   - fix entry point address calculation
 (suggested by Vladimir 'phcoder' Serbinenko),
   - fail if ELF file has relocs sections
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - reduce number of casts
 (suggested by Konrad Rzeszutek Wilk),
   - remove unneeded space at the end of line
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/i386/multiboot_mbi.c |   13 +++-
 grub-core/loader/multiboot.c  |   11 ++-
 grub-core/loader/multiboot_elfxx.c|  129 +
 grub-core/loader/multiboot_mbi2.c |  122 ++-
 include/grub/multiboot.h  |   22 +-
 include/multiboot2.h  |   24 ++
 6 files changed, 243 insertions(+), 78 deletions(-)

diff --git a/grub-core/loader/i386/multiboot_mbi.c 
b/grub-core/loader/i386/multiboot_mbi.c
index f60b702..fd7b41b 100644
--- a/grub-core/loader/i386/multiboot_mbi.c
+++ b/grub-core/loader/i386/multiboot_mbi.c
@@ -70,9 +70,18 @@ load_kernel (grub_file_t file, const char *filename,
 char *buffer, struct multiboot_header *header)
 {
   grub_err_t err;
+  mbi_load_data_t mld;
+
+  mld.file = file;
+  mld.filename = filename;
+  mld.buffer = buffer;
+  mld.mbi_ver = 1;
+  mld.relocatable = 0;
+  mld.avoid_efi_boot_services = 0;
+
   if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
 {
-  err = grub_multiboot_load_elf (file, filename, buffer);
+  err = grub_multiboot_load_elf ();
   if (err == GRUB_ERR_NONE) {
return GRUB_ERR_NONE;
   }
@@ -121,7 +130,7 @@ load_kernel (grub_file_t file, const char *filename,
   return GRUB_ERR_NONE;
 }
 
-  return grub_multiboot_load_elf (file, filename, buffer);
+  return grub_multiboo

[Xen-devel] [GRUB2 PATCH v6 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
On the other hand processor mode, just before jumping into loaded image, will
be set accordingly to Unified Extensible Firmware Interface Specification,
Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
loaded image will be able to use EFI boot services without any issues.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v6 - suggestions/fixes:
   - allocate memory for grub_relocator64_efi
 relocator between 0 and 4 GiB
 (suggested by Konrad Rzeszutek Wilk).

v4 - suggestions/fixes:
   - move EFI platform specific C code to separate file
 (suggested by Vladimir 'phcoder' Serbinenko),
   - add some comments
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - reuse grub-core/lib/i386/relocator64.S code
 instead of creating separate assembly file
 (suggested by Vladimir 'phcoder' Serbinenko),
   - grub_multiboot_boot() cleanup
 (suggested by Vladimir 'phcoder' Serbinenko),
   - reuse multiboot_header_tag_entry_address struct instead
 of creating new one for EFI 64-bit entry point
 (suggested by Vladimir 'phcoder' Serbinenko).
---
 grub-core/Makefile.core.def  |1 +
 grub-core/lib/i386/relocator64.S |   11 +
 grub-core/lib/x86_64/efi/relocator.c |   80 ++
 grub-core/loader/multiboot.c |   51 +++---
 grub-core/loader/multiboot_mbi2.c|   19 ++--
 include/grub/i386/multiboot.h|   11 +
 include/grub/i386/relocator.h|   21 +
 include/multiboot2.h |1 +
 8 files changed, 186 insertions(+), 9 deletions(-)
 create mode 100644 grub-core/lib/x86_64/efi/relocator.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 58b4208..21ad0dd 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1531,6 +1531,7 @@ module = {
   i386_xen = lib/i386/xen/relocator.S;
   x86_64_xen = lib/x86_64/xen/relocator.S;
   xen = lib/i386/relocator_common_c.c;
+  x86_64_efi = lib/x86_64/efi/relocator.c;
 
   extra_dist = lib/i386/relocator_common.S;
   extra_dist = kern/powerpc/cache_flush.S;
diff --git a/grub-core/lib/i386/relocator64.S b/grub-core/lib/i386/relocator64.S
index e4648d8..75725cf 100644
--- a/grub-core/lib/i386/relocator64.S
+++ b/grub-core/lib/i386/relocator64.S
@@ -73,6 +73,14 @@ VARIABLE(grub_relocator64_rsp)
 
movq%rax, %rsp
 
+   /*
+* Here is grub_relocator64_efi_start() entry point.
+* Following code is shared between grub_relocator64_efi_start()
+* and grub_relocator64_start().
+*
+* Think twice before changing anything below!!!
+*/
+VARIABLE(grub_relocator64_efi_start)
/* mov imm64, %rax */
.byte   0x48
.byte   0xb8
@@ -120,6 +128,9 @@ LOCAL(jump_addr):
 VARIABLE(grub_relocator64_rip)
.quad   0
 
+   /* Here grub_relocator64_efi_start() ends. Ufff... */
+VARIABLE(grub_relocator64_efi_end)
+
 #ifndef __x86_64__
.p2align4
 LOCAL(gdt):
diff --git a/grub-core/lib/x86_64/efi/relocator.c 
b/grub-core/lib/x86_64/efi/relocator.c
new file mode 100644
index 000..3caef7a
--- /dev/null
+++ b/grub-core/lib/x86_64/efi/relocator.c
@@ -0,0 +1,80 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *  Copyright (C) 2016  Oracle and/or its affiliates. All rights reserved.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+extern grub_uint64_t grub_relocator64_rax;
+extern grub_uint64_t grub_relocator64_rbx;
+extern grub_uint64_t grub_relocator64_rcx;
+extern grub_uint64_t grub_relocator64_rdx;
+extern grub_uint64_t grub_relocator64_rip;
+extern grub_uint64_t grub_relocator64_rsi;
+
+extern grub_uint8_t grub_relocator64_efi_start;
+extern grub_uint8_t grub_relocator64_efi_end;
+
+#define RELOCATOR_SIZEOF(x)(_relocator##x##_end - 
_relocator##x##_start)
+
+grub_err_t
+grub_relocator64_efi_boot (struct g

[Xen-devel] [GRUB2 PATCH v6 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,6 +755,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
   grub_fill_multiboot_mmap (tag);
@@ -776,6 +777,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
+  if (!keep_bs)
 {
   struct multiboot_tag_basic_meminfo *tag
= (struct multiboot_tag_basic_meminfo *) ptrorig;
@@ -886,21 +888,17 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
+if (!keep_bs)
+  {
tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
tag->size = sizeof (*tag) + efi_mmap_size;
 
-if (!keep_bs)
err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
 _desc_size, _desc_version);
-else
-  {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
-  }
+
if (err)
  return err;
+
tag->descr_size = efi_desc_size;
tag->descr_vers = efi_desc_version;
tag->size = sizeof (*tag) + efi_mmap_size;
@@ -908,6 +906,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
  / sizeof (grub_properly_aligned_t);
   }
+  }
 
   if (keep_bs)
 {
-- 
1.7.10.4


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

[Xen-devel] [GRUB2 PATCH v6 0/4] multiboot2: Add two extensions

[Daniel Kiper]

Hi,

This patch series:
  - enables EFI boot services usage in loaded images
by multiboot2 protocol,
  - add support for multiboot2 protocol compatible
relocatable images.

Daniel

 grub-core/Makefile.core.def   |1 +
 grub-core/lib/i386/relocator64.S  |   11 
 grub-core/lib/x86_64/efi/relocator.c  |   80 +
 grub-core/loader/i386/multiboot_mbi.c |   13 +++-
 grub-core/loader/multiboot.c  |   62 +++
 grub-core/loader/multiboot_elfxx.c|  131 
+---
 grub-core/loader/multiboot_mbi2.c |  256 
+-
 include/grub/i386/multiboot.h |   11 
 include/grub/i386/relocator.h |   21 +++
 include/grub/multiboot.h  |   22 ++-
 include/multiboot2.h  |   41 +
 11 files changed, 517 insertions(+), 132 deletions(-)

Daniel Kiper (4):
  i386/relocator: Add grub_relocator64_efi relocator
  multiboot2: Add tags used to pass ImageHandle to loaded image
  multiboot2: Do not pass memory maps to image if EFI boot services are 
enabled
  multiboot2: Add support for relocatable images


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

[Xen-devel] [GRUB2 PATCH v6 3/4 - FOR COMMIT] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

If image requested EFI boot services then skip multiboot2 memory maps.
Main reason for not providing maps is because they will likely be
invalid. We do a few allocations after filling them, e.g. for relocator
needs. Usually we do not care as we would have finished boot services.
If we keep boot services then it is easier/safer to not provide maps.
However, if image needs memory maps and they are not provided by bootloader
then it should get itself just before ExitBootServices() call.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v5 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
---
 grub-core/loader/multiboot_mbi2.c |   71 ++---
 1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 6c04402..ad1553b 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -390,7 +390,7 @@ static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
 #ifdef GRUB_MACHINE_EFI
-  if (!efi_mmap_size)
+  if (!keep_bs && !efi_mmap_size)
 find_efi_mmap_size ();
 #endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
@@ -755,12 +755,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   }
   }
 
-  {
-struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
-grub_fill_multiboot_mmap (tag);
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
-  }
+  if (!keep_bs)
+{
+  struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
+  grub_fill_multiboot_mmap (tag);
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct multiboot_tag_elf_sections *tag
@@ -776,18 +777,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
   / sizeof (grub_properly_aligned_t);
   }
 
-  {
-struct multiboot_tag_basic_meminfo *tag
-  = (struct multiboot_tag_basic_meminfo *) ptrorig;
-tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
-tag->size = sizeof (struct multiboot_tag_basic_meminfo); 
+  if (!keep_bs)
+{
+  struct multiboot_tag_basic_meminfo *tag
+   = (struct multiboot_tag_basic_meminfo *) ptrorig;
+  tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
+  tag->size = sizeof (struct multiboot_tag_basic_meminfo);
 
-/* Convert from bytes to kilobytes.  */
-tag->mem_lower = grub_mmap_get_lower () / 1024;
-tag->mem_upper = grub_mmap_get_upper () / 1024;
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
-  }
+  /* Convert from bytes to kilobytes.  */
+  tag->mem_lower = grub_mmap_get_lower () / 1024;
+  tag->mem_upper = grub_mmap_get_upper () / 1024;
+  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+   / sizeof (grub_properly_aligned_t);
+}
 
   {
 struct grub_net_network_level_interface *net;
@@ -886,27 +888,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 grub_efi_uintn_t efi_desc_size;
 grub_efi_uint32_t efi_desc_version;
 
-tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
 if (!keep_bs)
-  err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, NULL,
-  _desc_size, _desc_version);
-else
   {
-   if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
-NULL,
-_desc_size, _desc_version) <= 0)
- err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
NULL,
+_desc_size, _desc_version);
+
+   if (err)
+ return err;
+
+   tag->descr_size = efi_desc_size;
+   tag->descr_vers = efi_desc_version;
+   tag->size = sizeof (*tag) + efi_mmap_size;
+
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
   }
-if (err)
-  return err;
-tag->descr_size = efi_desc_size;
-tag->descr_vers = efi_desc_version;
-tag->size = sizeof (*tag) + efi_mmap_size;
-
-ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-  / sizeof (grub_properly_aligned_t);
   }
 
   if (keep_bs)
-- 
1.7.10.4


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

[Xen-devel] [GRUB2 PATCH v6 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

Add tags used to pass ImageHandle to loaded image if requested.
It is used by at least ExitBootServices() function.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v4 - suggestions/fixes:
   - reduce number of #ifdefs in grub_multiboot_get_mbi_size()
 (suggested by Vladimir 'phcoder' Serbinenko).

v3 - suggestions/fixes:
   - mbi EFI related stuff size calculation
 should depend on target architecture
 (suggested by Konrad Rzeszutek Wilk),
   - use plain type instead of pointer
 dereference as sizeof() argument
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 grub-core/loader/multiboot_mbi2.c |   42 ++---
 include/multiboot2.h  |   16 ++
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index a3dca90..6c04402 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char *filename)
  case MULTIBOOT_TAG_TYPE_NETWORK:
  case MULTIBOOT_TAG_TYPE_EFI_MMAP:
  case MULTIBOOT_TAG_TYPE_EFI_BS:
+ case MULTIBOOT_TAG_TYPE_EFI32_IH:
+ case MULTIBOOT_TAG_TYPE_EFI64_IH:
break;
 
  default:
@@ -407,13 +409,15 @@ grub_multiboot_get_mbi_size (void)
 + grub_get_multiboot_mmap_count ()
 * sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
-+ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
 + acpiv2_size ()
 + net_size ()
 #ifdef GRUB_MACHINE_EFI
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
 + ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+ efi_mmap_size, MULTIBOOT_TAG_ALIGN)
 #endif
@@ -907,11 +911,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
 
   if (keep_bs)
 {
-  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
-  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
-  tag->size = sizeof (struct multiboot_tag);
-  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
-   / sizeof (grub_properly_aligned_t);
+  {
+   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
+   tag->size = sizeof (struct multiboot_tag);
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+
+#ifdef __i386__
+  {
+   struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
+   tag->size = sizeof (struct multiboot_tag_efi32_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
+
+#ifdef __x86_64__
+  {
+   struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
ptrorig;
+   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
+   tag->size = sizeof (struct multiboot_tag_efi64_ih);
+   tag->pointer = (grub_addr_t) grub_efi_image_handle;
+   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+ / sizeof (grub_properly_aligned_t);
+  }
+#endif
 }
 #endif
 
diff --git a/include/multiboot2.h b/include/multiboot2.h
index 46e7b71..f5bebe1 100644
--- a/include/multiboot2.h
+++ b/include/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK   16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
 #define MULTIBOOT_TAG_TYPE_EFI_BS18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -371,6 +373,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

[Daniel Kiper]

On Tue, Mar 29, 2016 at 11:52:52AM +0200, Juergen Gross wrote:
> On 03/03/16 10:38, Juergen Gross wrote:
> > The Xen hypervisor supports starting a dom0 with large memory (up to
> > the TB range) by not including the initrd and p2m list in the initial
> > kernel mapping. Especially the p2m list can grow larger than the
> > available virtual space in the initial mapping.
> >
> > The started kernel is indicating the support of each feature via
> > elf notes.
> >
> > This series enables grub-xen to do the same as the hypervisor.
> >
> > Tested with:
> > - 32 bit domU (kernel not supporting unmapped initrd)
> > - 32 bit domU (kernel supporting unmapped initrd)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> > - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
>
> There has been no reaction for these patches for nearly 4 weeks now.
> Neither has there been any response regarding my request to include
> it in 2.02.

It looks that it will be taken into 2.02. Please check this email:
http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00281.html

Daniel

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

Re: [Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

On Tue, May 24, 2016 at 03:05:06AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33, <daniel.ki...@oracle.com> wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/boot/build32.lds
> > @@ -0,0 +1,49 @@
> > +/*
> > + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> > + *  Daniel Kiper <daniel.ki...@oracle.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along
> > + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +ENTRY(_start)
> > +
> > +SECTIONS
> > +{
> > +  /* Merge code and data into one section. */
> > +  .text : {
> > +*(.text)
> > +*(.text.*)
> > +*(.rodata)
>
> This (and the respective %.lnk rule change below) is not in line with
> the patch description. It's further suspicious that you only handle

I am not sure what exactly do you mean by that.

> .rodata but not also .rodata.* here.

I did this deliberately. I just want to take only these sections which I know 
that
contain required code and data. Nothing more. If in the future we find out that
.rodata.* (or anything else) is needed then we can add it later.

> > +  }
> > +
> > +  /DISCARD/ : {
> > +/*
> > + * .got.plt section is used only by dynamic linker
> > + * and our output is not supposed to be loaded by
> > + * dynamic linker. Additionally, it just contains
> > + * .PLT0 which is referenced from nowhere. So, we
> > + * can safely drop .got.plt here.
> > + *
> > + * Ha! This should be really discarded here. However,
> > + * .got.plt section contains _GLOBAL_OFFSET_TABLE_
> > + * symbol too and it is used as a reference for relative
> > + * addressing (and only for that thing). Hence, ld
> > + * complains if we remove that section because it
> > + * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
> > + * section during conversion to plain binary format.
> > + * Please check build32.mk for more details.
> > + */
> > +/* *(.got.plt) */
> > +  }
>
> I'm afraid this needs more investigation: Afaik there should be no

I am not sure what else we should look for.

> reason for the linker to create an otherwise empty .got.plt in the

As I wrote above. It contains _GLOBAL_OFFSET_TABLE_ which is used
as a reference for relative addressing.

> first place. And discarding it without being sure it is empty is not
> that good an idea anyway.

Good point! Potentially we can check is it empty, excluding 
_GLOBAL_OFFSET_TABLE_
symbol, in build32.mk.

Anyway, there is a chance that these tricks will not be needed at all. I will
try to link 32-bit code directly into Xen binary using objcopy, etc. which
we discussed during hackathon.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v6 0/4] multiboot2: Add two extensions

[Daniel Kiper]

Hey,

On Wed, Mar 30, 2016 at 05:06:15PM +0200, Daniel Kiper wrote:
> Hi,
>
> This patch series:
>   - enables EFI boot services usage in loaded images
> by multiboot2 protocol,
>   - add support for multiboot2 protocol compatible
> relocatable images.

Any chance to get it merged soon?

By the way, I am going to update multiboot2 proto doc and add description
of new features introduced by this patch series. Should I base my work
on multiboot2 branch found in git://git.savannah.gnu.org/grub.git?

Daniel

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

[Xen-devel] [PATCH v3 04/16] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
---
v3 - suggestions/fixes:
   - use "g" constraint instead of "r" for alloc_mem() bytes argument
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generalize new functions names
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   59 -
 1 file changed, 37 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 006f41d..d60a078 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -43,9 +43,10 @@ asm (
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_mem(u32 bytes)
 {
-void *new;
+u32 s;
+
 asm(
 "call 1f  \n"
 "1:  pop  %%edx   \n"
@@ -53,50 +54,64 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes)
 "sub  %1,%0   \n"
 "and  $~15,%0 \n"
 "mov  %0,alloc-1b(%%edx)  \n"
-"mov  %0,%%edi\n"
-"rep  movsb   \n"
-   : "=" (new), "+c" (bytes), "+S" (old)
-   : : "edx", "edi", "memory");
-return new;
+   : "=" (s) : "g" (bytes) : "edx", "memory");
+
+return s;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_mem(u32 src, u32 bytes)
 {
-char *p;
-for ( p = old; *p != '\0'; p++ )
+u32 dst, dst_asm;
+
+dst = alloc_mem(bytes);
+dst_asm = dst;
+
+asm volatile("rep movsb" : "+S" (src), "+D" (dst_asm), "+c" (bytes) : : 
"memory");
+
+return dst;
+}
+
+static u32 copy_string(u32 src)
+{
+u32 p;
+
+if ( src == 0 )
+return 0;
+
+for ( p = src; *(char *)p != '\0'; p++ )
 continue;
-return reloc_mbi_struct(old, p - old + 1);
+
+return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+multiboot_info_t *reloc(u32 mbi_old)
 {
-multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+multiboot_info_t *mbi = (multiboot_info_t *)copy_mem(mbi_old, 
sizeof(*mbi));
 int i;
 
 if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+mbi->cmdline = copy_string(mbi->cmdline);
 
 if ( mbi->flags & MBI_MODULES )
 {
-module_t *mods = reloc_mbi_struct(
-(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+module_t *mods;
 
-mbi->mods_addr = (u32)mods;
+mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+
+mods = (module_t *)mbi->mods_addr;
 
 for ( i = 0; i < mbi->mods_count; i++ )
 {
 if ( mods[i].string )
-mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+mods[i].string = copy_string(mods[i].string);
 }
 }
 
 if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = (u32)reloc_mbi_struct(
-(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
 
 if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = (u32)reloc_mbi_string(
-(char *)mbi->boot_loader_name);
+mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 07/16] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does
some code optimizations by creating data sections (e.g. jump addresses
for C switch/case are calculated using data in .rodata section). This
thing is not accepted by *.lnk build recipe which requires that only .text
section lives in output. Potentially we can inhibit this GCC behavior by
using special options, e.g. -fno-tree-switch-conversion. However, this
does not guarantee that in the future new similar optimizations or anything
which creates not accepted sections will not break our build recipes again.
Additionally, I do not mention that probably this is not good idea to just
disable random optimizations. So, take over full control on *.lnk linking
process by using linker script and merge all text and data sections into
one .text section.

Additionally, remove .got.plt section which is not used in our final code.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/boot/build32.lds |   49 +
 xen/arch/x86/boot/build32.mk  |   10 ++---
 2 files changed, 56 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/boot/build32.lds

diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
new file mode 100644
index 000..47db9c4
--- /dev/null
+++ b/xen/arch/x86/boot/build32.lds
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *  Daniel Kiper <daniel.ki...@oracle.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+ENTRY(_start)
+
+SECTIONS
+{
+  /* Merge code and data into one section. */
+  .text : {
+*(.text)
+*(.text.*)
+*(.rodata)
+  }
+
+  /DISCARD/ : {
+/*
+ * .got.plt section is used only by dynamic linker
+ * and our output is not supposed to be loaded by
+ * dynamic linker. Additionally, it just contains
+ * .PLT0 which is referenced from nowhere. So, we
+ * can safely drop .got.plt here.
+ *
+ * Ha! This should be really discarded here. However,
+ * .got.plt section contains _GLOBAL_OFFSET_TABLE_
+ * symbol too and it is used as a reference for relative
+ * addressing (and only for that thing). Hence, ld
+ * complains if we remove that section because it
+ * cannot find _GLOBAL_OFFSET_TABLE_. So, drop .got.plt
+ * section during conversion to plain binary format.
+ * Please check build32.mk for more details.
+ */
+/* *(.got.plt) */
+  }
+}
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a7d388..eb02b4b 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -12,20 +12,24 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
(od -v -t x $< | tr -s ' ' | awk 'NR > 1 {print s} {s=$$0}' | \
sed 's/ /,0x/g' | sed 's/,0x$$//' | sed 's/^[0-9]*,/ .long /') >$@
 
+#
+# Drop .got.plt during conversion to plain binary format.
+# Please check build32.lds for more details.
+#
 %.bin: %.lnk
-   $(OBJCOPY) -O binary $< $@
+   $(OBJCOPY) -O binary -R .got.plt $< $@
 
 %.lnk: %.o
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.rodata.*|.bss|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
esac; \
done
-   $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<
+   $(LD) $(LDFLAGS_DIRECT) -N -T build32.lds -o $@ $<
 
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 03/16] x86/boot: call reloc() using cdecl calling convention

[Daniel Kiper]

reloc() is not called according to cdecl calling convention.
This makes confusion and does not scale well for more arguments.
And patch adding multiboot2 protocol support have to pass 3
arguments instead of 2. Hence, move reloc() call to cdecl
calling convention.

I add push %ebp/mov %esp,%ebp/leave instructions here. Though they
are not strictly needed in this patch. However, then assembly code
in patch adding multiboot2 protocol support is easier to read.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - simplify assembly in xen/arch/x86/boot/reloc.c file
 (suggested by Jan Beulich),
   - reorder arguments for reloc() call from xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |4 +++-
 xen/arch/x86/boot/reloc.c |   18 ++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 32a54a0..28ac721 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -119,8 +119,10 @@ __start:
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%ebx
+push%eax/* Boot trampoline address. */
+push%ebx/* Multiboot information address. */
 callreloc
+add $8,%esp /* Remove reloc() args from stack. */
 mov %eax,sym_phys(multiboot_ptr)
 
 /* Initialize BSS (no nasty surprises!). */
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..006f41d 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,15 +10,25 @@
  *Keir Fraser <k...@xen.org>
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
+ */
 asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
+"push %ebp \n"
+"mov  %esp,%ebp\n"
 "call 1f   \n"
-"1:  pop  %ebx \n"
-"mov  %eax,alloc-1b(%ebx)  \n"
-"jmp  reloc\n"
+"1:  pop  %ecx \n"
+"mov  0xc(%ebp),%eax   \n"
+"mov  %eax,alloc-1b(%ecx)  \n"
+"push 0x8(%ebp)\n"
+"call reloc\n"
+"leave \n"
+"ret   \n"
 );
 
 /*
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

Existing solution does not allocate space for this symbol and any
references to acpi20, etc. does not make sense. As I saw any efi.*
references are protected by relevant ifs but we should not do that
because it makes code very fragile. If somebody does not know how
efi symbol is created he/she may assume that it always represent
valid structure and do invalid references somewhere.

Additionally, following patch adds efi struct flags member which
is used during runtime to differentiate between legacy BIOS and
EFI platforms and multiboot2 and EFI native loader. So, efi symbol
have to proper representation in ELF and PE Xen image. Hence,
define efi struct in xen/arch/x86/efi/stub.c and remove efi
symbol from ld script.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/efi/stub.c |8 
 xen/arch/x86/xen.lds.S  |2 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..e6c99b5 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -8,6 +8,14 @@
 const bool_t efi_enabled = 0;
 #endif
 
+struct efi __read_mostly efi = {
+   .acpi= EFI_INVALID_TABLE_ADDR,
+   .acpi20  = EFI_INVALID_TABLE_ADDR,
+   .mps = EFI_INVALID_TABLE_ADDR,
+   .smbios  = EFI_INVALID_TABLE_ADDR,
+   .smbios3 = EFI_INVALID_TABLE_ADDR
+};
+
 void __init efi_init_memory(void) { }
 
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { }
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6802da1..6376bfa 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -227,8 +227,6 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
   /* Sections to be discarded */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 01/16] x86/boot: do not create unwind tables

[Daniel Kiper]

This way .eh_frame section is not included in *.lnk and *.bin files.
Hence, final e.g. reloc.bin file size is reduced from 408 bytes to
272 bytes and it contains only used code and data.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/boot/build32.mk |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a1421f..4a7d388 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -4,7 +4,7 @@ include $(XEN_ROOT)/Config.mk
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 
-CFLAGS += -Werror -fno-builtin -msoft-float
+CFLAGS += -Werror -fno-asynchronous-unwind-tables -fno-builtin -msoft-float
 CFLAGS := $(filter-out -flto,$(CFLAGS)) 
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 16/16] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   46 +
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +++
 3 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e322270..dbf2555 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -79,6 +79,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offset(start), /* Min load address. */ \
+   0x, /* Max load address (4 GiB - 1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -178,30 +185,39 @@ efi_multiboot2_proto:
 and $~(MULTIBOOT2_TAG_ALIGN-1),%rcx
 
 0:
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%rcx)
+jne 1f
+
+mov MB2_load_base_addr(%rcx),%r15d
+sub $XEN_IMG_OFFSET,%r15
+jmp 4f
+
+1:
 /* Get EFI SystemTable address from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
-jne 1f
+jne 2f
 
 mov MB2_efi64_st(%rcx),%rsi
 
 /* Do not clear BSS twice and do not go into real mode. */
 movb$1,skip_realmode(%rip)
-jmp 3f
+jmp 4f
 
-1:
+2:
 /* Get EFI ImageHandle address from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI64_IH,MB2_tag_type(%rcx)
-jne 2f
+jne 3f
 
 mov MB2_efi64_ih(%rcx),%rdi
-jmp 3f
+jmp 4f
 
-2:
+3:
 /* Is it the end of Multiboot2 information? */
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
 je  run_bs
 
-3:
+4:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%rcx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%rcx
@@ -313,14 +329,23 @@ multiboot2_proto:
 and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
 
 0:
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne 1f
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp 3f
+
+1:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
-jne 1f
+jne 2f
 
 mov MB2_mem_lower(%ecx),%edx
-jmp trampoline_bios_setup
+jmp 3f
 
-1:
+2:
 /* EFI mode is not supported via legacy BIOS path. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
 je  mb2_too_old
@@ -332,6 +357,7 @@ multiboot2_proto:
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
 je  trampoline_bios_setup
 
+3:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%ecx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index b7aed49..d227f28 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -172,6 +172,7 @@ void __dummy__(void)
 DEFINE(MB2_fixed_sizeof, sizeof(multiboot2_fixed_t));
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 0f113f1..a1d355c 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h

[Xen-devel] [PATCH v3 13/16 - RFC] x86: add multiboot2 protocol support for EFI platforms

[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 <daniel.ki...@oracle.com>
---
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).

v3 - not fixed yet:
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 should print error message and halt system.

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  |  177 +++--
 xen/arch/x86/efi/efi-boot.h   |   43 +
 xen/arch/x86/efi/stub.c   |5 ++
 xen/arch/x86/setup.c  |   10 ++-
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   12 +++
 xen/include/xen/efi.h |1 +
 8 files changed, 240 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e46d691..efb0614 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)
 multiboot2_header_end:
@@ -100,19 +107,29 @@ multiboot2_header_end:
 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
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 .Lbad_ldr_msg: .asciz "ERR: Not a Multiboot bootloader!"
+.Lbad_ldr_mb2: .asciz "ERR: On EFI platform use latest Multiboot2 compatible 
bootloader!"
 
 .section .init.text, "ax", @progbits
 
 bad_cpu:
 mov $(sym_phys(.Lbad_cpu_msg)),%esi # Error message
-jmp print_err
+mov $0xB8000,%edi   # VGA framebuffer
+jmp 1f
 not_multiboot:
 mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
-mov $0xB8000,%edi  # VGA framebuffer
+mov $0xB8000,%edi   # VGA framebuffer
+jmp 1f
+mb2_too_old:
+mov $(sym_phys(.Lbad_ldr_mb2)),%esi # Error message
+xor %edi,%edi   # No VGA framebuffer
 1:  mov (%esi),%bl
 test%bl,%bl# Terminate on '\0' sentinel
 je  .Lhalt
@@ -123,6 +140,8 @@ print_err:
 mov $0x3f8+0,%dx   # UART Transmit Holding Register
 mov %bl,%al
 out %al,%dx# Send a character over the serial line
+test%edi,%edi  # Is VGA framebuffer available?
+jz  1b
 movsb  # Write a character to the VGA framebuffer
 mov $7,%al
 stosb  # Write an attribute to the VGA framebuffer
@@ -130,6 +149,130 @@ print_err:
 .Lhalt: hlt
 jmp .Lhalt
 
+.code64
+
+__efi64_start:
+cld
+
+/* Check for Multiboot2 bootloader. */
+cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
+je  efi_multiboot2_proto
+
+/* Jump to not_multiboot after switching CPU to x86_32 mode. */
+lea not_multiboot(%rip),%rdi
+jmp x86_32_switch
+
+efi_multiboot2_proto:
+/*
+ * Multiboot2 information address is 32-bit,
+ * so, zero higher half of %rbx.
+ */
+mov %ebx,%ebx
+
+/* Skip Multiboot2 information fixed part. */
+lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%rcx
+and $~(MULTIBOOT2_TAG_ALIGN-1),%rcx
+
+0:
+/* Get EFI SystemTable address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%rcx)
+jne 1f
+
+mo

[Xen-devel] [PATCH v3 00/16] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending, long awaited, third version of multiboot2 protocol
support for legacy BIOS and EFI platforms. It fixes all major issues
discovered until now. There are still some minor problems which should
be fixed in one way or another. I will address them in next releases.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here are short list of changes:
  - new patches: 01, 07, 09,
  - changed patches: 02, 03, 04, 06, 08, 10, 11, 13, 14, 15, 16,
  - RFC patches: 12, 13, 15; if it is needed we could discuss at
least #12 and #15 at Xen Project Hackathon in Cambridge.

This patch series was build with following tools:
  - gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
and binutils 2.17-3+etch1,
  - gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
and binutils 2.23.2-2.el6,
  - gcc version 4.7.2 (Debian 4.7.2-5)
and binutils 2.22-8,
  - gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
and binutils 2.25-9.fc22.

I hope that starting from now there will be faster turnaround
of this patch series.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 .gitignore|5 +-
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |4 +
 xen/arch/x86/boot/Makefile|   10 +-
 xen/arch/x86/boot/build32.lds |   50 +
 xen/arch/x86/boot/build32.mk  |   14 ++-
 xen/arch/x86/boot/cmdline.S   |  367 
--
 xen/arch/x86/boot/cmdline.c   |  357 
+
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  481 
+-
 xen/arch/x86/boot/reloc.c |  246 
+++---
 xen/arch/x86/boot/trampoline.S|   18 +++-
 xen/arch/x86/boot/video.S |6 --
 xen/arch/x86/boot/wakeup.S|6 +-
 xen/arch/x86/boot/x86_64.S|   44 +++-
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   11 +-
 xen/arch/x86/efi/efi-boot.h   |   81 --
 xen/arch/x86/efi/stub.c   |   16 ++-
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   61 ++-
 xen/arch/x86/shutdown.c   |2 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   10 ++
 xen/arch/x86/xen.lds.S|7 +-
 xen/common/efi/boot.c |   19 
 xen/common/efi/runtime.c  |   23 ++--
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/config.h  |1 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |   13 ++-
 xen/include/xen/multiboot2.h  |  182 +++
 33 files changed, 1491 insertions(+), 570 deletions(-)

Daniel Kiper (16):
  x86/boot: do not create unwind tables
  x86: zero BSS using stosl instead of stosb
  x86/boot: call reloc() using cdecl calling convention
  x86/boot/reloc: create generic alloc and copy functions
  x86/boot: use %ecx instead of %eax
  x86/boot/reloc: Rename some variables and rearrange code a bit
  x86/boot: create *.lnk files with linker script
  x86: add multiboot2 protocol support
  efi: explicitly define efi struct in xen/arch/x86/efi/stub.c
  efi: create efi_enabled()
  efi: build xen.gz with EFI code
  x86/efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: make Xen early boot code relocatable
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v3 11/16] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/efi/Makefile |   11 +++
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |6 ++
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..2a7d3e5 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,9 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
+efi := $(if $(efi),$(shell rm disabled)y)
 
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index f006575..d10c0ab 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1244,6 +1244,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index aa064e7..3eb21c1 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -167,6 +167,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
 unsigned int i, n;
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return -EOPNOTSUPP;
+
 switch ( idx )
 {
 case XEN_FW_EFI_VERSION:
@@ -301,6 +304,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
 EFI_STATUS status = EFI_NOT_STARTED;
 int rc = 0;
 
+if ( !efi_enabled(EFI_PLATFORM) )
+return -EOPNOTSUPP;
+
 switch ( op->function )
 {
 case XEN_EFI_get_time:
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of Multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  106 +--
 xen/arch/x86/boot/reloc.c |  152 -
 xen/arch/x86/x86_64/asm-offsets.c |7 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 427 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 1ff5937..e46d691 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,28 @@
 #define BOOT_PSEUDORM_CS 0x0020
 #define BOOT_PSEUDORM_DS 0x0028
 
+#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
+#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
+
+.macro mb2ht_args arg, args:vararg
+.long \arg
+.ifnb \args
+mb2ht_args \args
+.endif
+.endm
+
+.macro mb2ht_init type, req, args:vararg
+.align MULTIBOOT2_TAG_ALIGN
+.Lmb2ht_init_start\@:
+.short \type
+.short \req
+.long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
+.ifnb \args
+mb2ht_args \args
+.endif
+.Lmb2ht_init_end\@:
+.endm
+
 ENTRY(start)
 jmp __start
 
@@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
 multiboot1_header_end:
 
+/*** MULTIBOOT2 HEADER /
+/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
file. */
+.align  MULTIBOOT2_HEADER_ALIGN
+
+multiboot2_header_start:
+/* Magic number indicating a Multiboot2 header. */
+.long   MULTIBOOT2_HEADER_MAGIC
+/* Architecture: i386. */
+.long   MULTIBOOT2_ARCHITECTURE_I386
+/* Multiboot2 header length. */
+.long   multiboot2_header_end - multiboot2_header_start
+/* Multiboot2 header checksum. */
+.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + \
+(multiboot2_header_end - multiboot2_header_start))
+
+/* Multiboot2 information request tag. */
+mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
+   MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
+
+/* Align modules at page b

[Xen-devel] [PATCH v3 02/16] x86: zero BSS using stosl instead of stosb

[Daniel Kiper]

Speedup BSS initialization by using stosl instead of stosb.

Some may argue that Intel Ivy Bridge and later provide ERMSB feature.
This means that "rep stosb" gives better throughput than "rep stosl" on
above mentioned CPUs. However, this feature is only available on newer
Intel processors and e.g. AMD does not provide it at all. So, stosb will
just give real benefits and even beat stosl only on limited number of
machines. On the other hand stosl will speedup BSS initialization on
all x86 platforms. Hence, use stosl instead of stosb.

Additionally, align relevant comment to coding style.

Suggested-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S |5 +++--
 xen/arch/x86/xen.lds.S   |3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f3501fd..32a54a0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -123,12 +123,13 @@ __start:
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
 
-/* Initialize BSS (no nasty surprises!) */
+/* Initialize BSS (no nasty surprises!). */
 mov $sym_phys(__bss_start),%edi
 mov $sym_phys(__bss_end),%ecx
 sub %edi,%ecx
+shr $2,%ecx
 xor %eax,%eax
-rep stosb
+rep stosl
 
 /* Interrogate CPU extended features via CPUID. */
 mov $0x8000,%eax
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 961f48f..6802da1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -191,6 +191,8 @@ SECTIONS
CONSTRUCTORS
   } :text
 
+  /* Align BSS to speedup its initialization. */
+  . = ALIGN(4);
   .bss : { /* BSS */
. = ALIGN(STACK_SIZE);
__bss_start = .;
@@ -205,6 +207,7 @@ SECTIONS
*(.bss.percpu.read_mostly)
. = ALIGN(SMP_CACHE_BYTES);
__per_cpu_data_end = .;
+   . = ALIGN(4);
__bss_end = .;
   } :text
   _end = . ;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 05/16] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
 xen/arch/x86/boot/head.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 28ac721..1ff5937 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -87,14 +87,14 @@ __start:
 jne not_multiboot
 
 /* Set up trampoline segment 64k below EBDA */
-movzwl  0x40e,%eax  /* EBDA segment */
-cmp $0xa000,%eax/* sanity check (high) */
+movzwl  0x40e,%ecx  /* EBDA segment */
+cmp $0xa000,%ecx/* sanity check (high) */
 jae 0f
-cmp $0x4000,%eax/* sanity check (low) */
+cmp $0x4000,%ecx/* sanity check (low) */
 jae 1f
 0:
-movzwl  0x413,%eax  /* use base memory size on failure */
-shl $10-4,%eax
+movzwl  0x413,%ecx  /* use base memory size on failure */
+shl $10-4,%ecx
 1:
 /*
  * Compare the value in the BDA with the information from the
@@ -106,20 +106,20 @@ __start:
 cmp $0x100,%edx /* is the multiboot value too small? */
 jb  2f  /* if so, do not use it */
 shl $10-4,%edx
-cmp %eax,%edx   /* compare with BDA value */
-cmovb   %edx,%eax   /* and use the smaller */
+cmp %ecx,%edx   /* compare with BDA value */
+cmovb   %edx,%ecx   /* and use the smaller */
 
 2:  /* Reserve 64kb for the trampoline */
-sub $0x1000,%eax
+sub $0x1000,%ecx
 
 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-xor %al, %al
-shl $4, %eax
-mov %eax,sym_phys(trampoline_phys)
+xor %cl, %cl
+shl $4, %ecx
+mov %ecx,sym_phys(trampoline_phys)
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%eax/* Boot trampoline address. */
+push%ecx/* Boot trampoline address. */
 push%ebx/* Multiboot information address. */
 callreloc
 add $8,%esp /* Remove reloc() args from stack. */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 14/16] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Suggested-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |7 +-
 xen/arch/x86/boot/build32.lds  |1 +
 xen/arch/x86/boot/build32.mk   |4 +-
 xen/arch/x86/boot/cmdline.S|  367 
 xen/arch/x86/boot/cmdline.c|  357 ++
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |   17 ++
 xen/arch/x86/boot/trampoline.S |   12 ++
 xen/arch/x86/boot/video.S  |6 -
 11 files changed, 400 insertions(+), 381 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c

diff --git a/.gitignore b/.gitignore
index 91f690c..6919546 100644
--- a/.gitignore
+++ b/.gitignore
@@ -237,9 +237,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 1bcb08b..32d2407 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -176,4 +176,4 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..d73cc76 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,14 @@
 obj-bin-y += head.o
 
+CMDLINE_DEPS = video.h
+
 RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
 $(BASEDIR)/include/xen/multiboot2.h
 
-head.o: reloc.S
+head.o: cmdline.S reloc.S
+
+cmdline.S: cmdline.c $(CMDLINE_DEPS)
+   $(MAKE) -f build32.mk $@ CMDLINE_DEPS="$(CMDLINE_DEPS)"
 
 reloc.S: reloc.c $(RELOC_DEPS)
$(MAKE) -f build32.mk $@ RELOC_DEPS="$(RELOC_DEPS)"
diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
index 47db9c4..6a234ea 100644
--- a/xen/arch/x86/boot/build32.lds
+++ b/xen/arch/x86/boot/build32.lds
@@ -25,6 +25,7 @@ SECTIONS
 *(.text)
 *(.text.*)
 *(.rodata)
+*(.rodata.*)
   }
 
   /DISCARD/ : {
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index eb02b4b..58e27e1 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -23,7 +23,7 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.bss|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
@@ -34,6 +34,8 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
 
+cmdline.o: cmdline.c $(CMDLINE_DEPS)
+
 reloc.o: reloc.c $(RELOC_DEPS)
 
 .PRECIOUS: %.bin %.lnk
diff --git a/xen/arch/x86/boot/cmdline.S b/xen/arch/x86/boot/cmdline.S
deleted file mode 100644
index 00687eb..000
--- a/xen/arch/x86/boot/cmdline.S
+++ /dev/null
@@ -1,367 +0,0 @@
-/**
- * cmdline.S
- *
- * Early command-line parsing.
- */
-
-.code32
-
-#includ

[Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi.flags. This patch only defines
EFI_PLATFORM feature which is equal to old efi_enabled == 1.
Following patch will define EFI_LOADER feature accordingly.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|5 +
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   10 +-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |4 
 xen/common/efi/runtime.c   |   17 +++--
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |   12 ++--
 11 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index 8e07f8d..4cd38c8 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_PLATFORM)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -702,7 +702,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_PLATFORM) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..fdf0d8a 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_enabled(EFI_PLATFORM) && efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index e6c99b5..c5ae369 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,11 +4,8 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
-
 struct efi __read_mostly efi = {
+   .flags   = 0, /* Initialized later. */
.acpi= EFI_INVALID_TABLE_ADDR,
.acpi20  = EFI_INVALID_TABLE_ADDR,
.mps = EFI_INVALID_TABLE_ADDR,
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index ef6557c..ff26b5a 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -564,7 +564,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-   if (efi_enabled)
+   if (efi_enabled(EFI_PLATFORM))
clear_fixmap(FIX_EFI_MPF);
 }
 
@@ -722,7 +722,7 @@ void __init find_smp_config (void)
 {
unsigned int address;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_PLATFORM)) {
efi_check_config();
return;
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c5c332d..5d80868 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -434,8 +434,8 @@ static void __init parse_video_info(void)
 {
 struct boot_video_info *bvi = (boot_vid_info);
 
-/* The EFI loader fills vga_console_info directly. */
-if ( efi_enabled )
+/* vga_console_info is filled directly on EFI platform. */
+if ( efi_enabled(EFI_PLATFORM) )
 return;
 
 if ( (bvi->orig_video_isVGA == 1) && (bvi->orig_video_mode == 3) )
@@ -715,7 +715,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( !(mbi->flags & MBI_MODULES) || (mbi->mods_count == 0) )
 panic("dom0 kernel not specified. Check bootloader configuration.");
 
-if ( efi_enabled )
+if ( efi_enabled(

[Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and
going down. Sadly this does not work when Xen is loaded using multiboot2
protocol because start lives on 1 MiB address. So, I tried to use
mem_lower address calculated by GRUB2. However, it works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((

In case of multiboot2 protocol we need that place_string() only allocate
memory chunk for EFI memory map. However, I think that it should be fixed
instead of making another function used just in one case. I thought about
two solutions.

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   this in e820 memory map and map it in Xen virtual address space.
   In later case we must also care about conflicts with e.g. crash
   kernel regions which could be quite difficult.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase
   Xen binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we want to use this memory pool for Xen and modules
   command line storage (it would be used when xen.efi is executed as EFI
   application) then we should add, I think, about 1 KiB. In this case,
   to be on safe side, we should assume at least 64 KiB pool for early
   memory allocations, which is about 4 times of our earlier calculations.
   However, during discussion on Xen-devel Jan Beulich suggested that
   just in case we should use 1 MiB memory pool like it was in original
   place_string() implementation. So, let's use 1 MiB as it was proposed.
   If we think that we should not waste unallocated memory in the pool
   on running system then we can mark this region as __initdata and move
   all required data to dynamically allocated places somewhere in __start_xen().

Now solution #2 is implemented but maybe we should consider #1 one day.

Jan Beulich added 1b) Do away with efi_arch_allocate_mmap_buffer() and use
   AllocatePages() uniformly, perhaps with a per-arch specified memory type
   (by means of which you can control whether the memory contents will remain
   preserved until the time you want to look at it). That will eliminate the
   only place_string() you're concerned about, with a patch with better
   diffstat (largely due to the questionable arch hook gone).

However, this solution does not solve conflicts problem described in #1
because EFI memory map is needed during Xen runtime after init phase.
So, finally we would get back to #1. Hmmm... Should I check how Linux
and others cope with that problem?

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/efi/efi-boot.h |   38 ++
 xen/arch/x86/setup.c|3 +--
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 6dbb14d..84afffa 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,36 @@ static void __init relocate_trampoline(unsigned long phys)
 *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define EBMALLOC_SIZE  MB(1)
+
+static char __initdata ebmalloc_mem[EBMALLOC_SIZE];
+static char __initdata *ebmalloc_free = NULL;
+
+/* EFI boot allocator. */
+static void __init *ebmalloc(size_t size)
+{
+void *ptr;
+
+/*
+ * Init ebmalloc_free on runtime. Static initialization
+ * will not work because it puts virtual address there.
+ */
+if ( ebmalloc_free == NULL )
+ebmalloc_free = ebmalloc_mem;
+
+ptr = ebmalloc_free;
+
+ebmalloc_free += size;
+
+if ( ebmalloc_free - ebmalloc_mem > sizeof(ebmalloc_mem) )
+blexit(L"Out of static memory\r\n");
+
+return ptr;
+}
+
 static void __init place_string(u32 *addr, const char *s)
 {
-static char *__initdata alloc = start;
+char *alloc = NULL;
 
 if ( s && *s )
 {
@@ -113,7 +140,7 @@ static void __init place_string(u32 *addr, const char *s)
 const char *old = (char *)(long)*addr;
 size_t len2 = *addr ? strlen(old) + 1 : 0;
 
-alloc -= len1 + len2;
+   

[Xen-devel] [PATCH v3 06/16] x86/boot/reloc: Rename some variables and rearrange code a bit

[Daniel Kiper]

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code
a bit to make it more readable. Additionally, this way multiboot (v1)
protocol implementation and future multiboot2 protocol implementation
will use the same variable naming convention.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
---
v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - extract this change from main mutliboot2
 protocol implementation
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   39 +--
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index d60a078..93b3845 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -84,41 +84,44 @@ static u32 copy_string(u32 src)
 return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t *reloc(u32 mbi_old)
+multiboot_info_t *reloc(u32 mbi_in)
 {
-multiboot_info_t *mbi = (multiboot_info_t *)copy_mem(mbi_old, 
sizeof(*mbi));
 int i;
+multiboot_info_t *mbi_out;
 
-if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = copy_string(mbi->cmdline);
+mbi_out = (multiboot_info_t *)copy_mem(mbi_in, sizeof(*mbi_out));
 
-if ( mbi->flags & MBI_MODULES )
+if ( mbi_out->flags & MBI_CMDLINE )
+mbi_out->cmdline = copy_string(mbi_out->cmdline);
+
+if ( mbi_out->flags & MBI_MODULES )
 {
 module_t *mods;
 
-mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+mbi_out->mods_addr = copy_mem(mbi_out->mods_addr,
+  mbi_out->mods_count * sizeof(module_t));
 
-mods = (module_t *)mbi->mods_addr;
+mods = (module_t *)mbi_out->mods_addr;
 
-for ( i = 0; i < mbi->mods_count; i++ )
+for ( i = 0; i < mbi_out->mods_count; i++ )
 {
 if ( mods[i].string )
 mods[i].string = copy_string(mods[i].string);
 }
 }
 
-if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
+if ( mbi_out->flags & MBI_MEMMAP )
+mbi_out->mmap_addr = copy_mem(mbi_out->mmap_addr, 
mbi_out->mmap_length);
 
-if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+if ( mbi_out->flags & MBI_LOADERNAME )
+mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
-mbi->flags &= (MBI_MEMLIMITS |
-   MBI_CMDLINE |
-   MBI_MODULES |
-   MBI_MEMMAP |
-   MBI_LOADERNAME);
+mbi_out->flags &= (MBI_MEMLIMITS |
+   MBI_CMDLINE |
+   MBI_MODULES |
+   MBI_MEMMAP |
+   MBI_LOADERNAME);
 
-return mbi;
+return mbi_out;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v3 15/16 - RFC] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1 MiB and ends at 17 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with
that problem we must make Xen early boot code relocatable. This patch does
that. However, it does not add multiboot2 protocol interface which is done
in "x86: add multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - default load address is changed from 1 MiB to 2 MiB; I did that because
initial page tables are using 2 MiB huge pages and this way required
updates for them are quite easy; it means that e.g. we avoid spacial
cases for start and end of required memory region if it live at address
not aligned to 2 MiB,
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls,
  - %esi is used as base for Xen data relative addressing in 32-bit code.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v3 - not fixed yet:
   - small issue with remapping code in xen/arch/x86/setup.c,
   -  mkelf32 argument should
 be calculated dynamically; this issue has
 minimal impact on other parts of this patch.
---
 xen/arch/x86/Makefile  |6 +-
 xen/arch/x86/Rules.mk  |4 +
 xen/arch/x86/boot/head.S   |  162 ++--
 xen/arch/x86/boot/trampoline.S |6 +-
 xen/arch/x86/boot/wakeup.S |6 +-
 xen/arch/x86/boot/x86_64.S |   44 +--
 xen/arch/x86/setup.c   |   44 ++-
 xen/arch/x86/xen.lds.S |2 +-
 xen/include/asm-x86/config.h   |1 +
 xen/include/asm-x86/page.h |2 +-
 10 files changed, 186 insertions(+), 91 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 32d2407..0cc6f5f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -71,8 +71,10 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h 
-o \
  echo '$(TARGET).efi'; fi)
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
-   `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+#  THIS IS UGLY HACK! PLEASE DO NOT COMPLAIN. I WILL FIX IT IN NEXT 
RELEASE.
+   ./boot/mkelf32 $(TARGET)-syms $(TARGET) $(XEN_IMG_OFFSET) 
0x82d08100
+#  ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
+#  `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
 
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 3139886..7c76f80 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,6 +1,10 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET = 0x20
+
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 964851b..e322270 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,7 +12,7 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_offset(sym)   ((sym) - __XEN_VIRT_START)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -94,7 +94,7 @@ multiboot2_header_start:
 
 /* EFI64 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_start)
+   sym_offset(__efi64_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -106,11 +106,12 @@ multi

Re: [Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

[Daniel Kiper]

On Tue, May 24, 2016 at 09:46:13AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33,  wrote:
> > @@ -19,6 +20,28 @@
> >  #define BOOT_PSEUDORM_CS 0x0020
> >  #define BOOT_PSEUDORM_DS 0x0028
> >
> > +#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
> > +#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
> > +
> > +.macro mb2ht_args arg, args:vararg
> > +.long \arg
> > +.ifnb \args
> > +mb2ht_args \args
> > +.endif
> > +.endm
> > +
> > +.macro mb2ht_init type, req, args:vararg
>
> If you already use :vararg here and above, please also use :req on
> the other macro arguments.

Why?

> > @@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER 
> > /
> >  .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
> >  multiboot1_header_end:
> >
> > +/*** MULTIBOOT2 HEADER /
> > +/* Some ideas are taken from grub-2.00/grub-core/tests/boot/kernel-i386.S 
> > file. */
> > +.align  MULTIBOOT2_HEADER_ALIGN
> > +
> > +multiboot2_header_start:
> > +/* Magic number indicating a Multiboot2 header. */
> > +.long   MULTIBOOT2_HEADER_MAGIC
> > +/* Architecture: i386. */
> > +.long   MULTIBOOT2_ARCHITECTURE_I386
> > +/* Multiboot2 header length. */
> > +.long   multiboot2_header_end - multiboot2_header_start
> > +/* Multiboot2 header checksum. */
> > +.long   -(MULTIBOOT2_HEADER_MAGIC + MULTIBOOT2_ARCHITECTURE_I386 + 
> > \
> > +(multiboot2_header_end - multiboot2_header_start))
> > +
> > +/* Multiboot2 information request tag. */
> > +mb2ht_init MB2_HT(INFORMATION_REQUEST), MB2_HT(REQUIRED), \
> > +   MB2_TT(BASIC_MEMINFO), MB2_TT(MMAP)
> > +
> > +/* Align modules at page boundry. */
> > +mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
> > +
> > +/* Console flags tag. */
> > +mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
> > +   MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
> > +
> > +/* Framebuffer tag. */
> > +mb2ht_init MB2_HT(FRAMEBUFFER), MB2_HT(OPTIONAL), \
> > +   0, /* Number of the columns - no preference. */ \
> > +   0, /* Number of the lines - no preference. */ \
> > +   0  /* Number of bits per pixel - no preference. */
> > +
> > +/* Multiboot2 header end tag. */
> > +mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
> > +multiboot2_header_end:
>
> Imo "end" labels should always preferably be .L-prefixed, to avoid
> them getting used by a consumer instead of another "proper" label
> starting whatever comes next.

Make sense, however, I am in line with multiboot1_header_end label here.
So, if we wish .L here then we should change multiboot1_header_end label
above too. Of course in separate patch.

> > @@ -82,10 +141,49 @@ __start:
> >  mov %ecx,%es
> >  mov %ecx,%ss
> >
> > -/* Check for Multiboot bootloader */
> > +/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero 
> > value. */
> > +xor %edx,%edx
> > +
> > +/* Check for Multiboot2 bootloader. */
> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
> > +je  multiboot2_proto
> > +
> > +/* Check for Multiboot bootloader. */
> >  cmp $MULTIBOOT_BOOTLOADER_MAGIC,%eax
> >  jne not_multiboot
> >
> > +/* Get mem_lower from Multiboot information. */
> > +testb   $MBI_MEMLIMITS,MB_flags(%ebx)
> > +
> > +/* Not available? BDA value will be fine. */
> > +cmovnz  MB_mem_lower(%ebx),%edx
> > +jmp trampoline_setup
> > +
> > +multiboot2_proto:
> > +/* Skip Multiboot2 information fixed part. */
> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%ebx),%ecx
> > +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +
> > +0:
> > +/* Get mem_lower from Multiboot2 information. */
> > +cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
> > +jne 1f
> > +
> > +mov MB2_mem_lower(%ecx),%edx
> > +jmp trampoline_setup
> > +
> > +1:
> > +/* Is it the end of Multiboot2 information? */
> > +cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
> > +je  trampoline_setup
> > +
> > +/* Go to next Multiboot2 information tag. */
> > +add MB2_tag_size(%ecx),%ecx
> > +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +jmp 0b
>
> I'm missing a total size check, matching what meanwhile got added
> to the C equivalent(s) of this loop. There's little point in doing it
> there if it doesn't also get done here.

OK.

> > @@ -41,7 +45,16 @@ asm (
> >  );
> >
> >  typedef unsigned int u32;
> > +typedef unsigned long long u64;
> > +
> >  #include 

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >>> On 15.04.16 at 14:33,  wrote:
> > Existing solution does not allocate space for this symbol and any
> > references to acpi20, etc. does not make sense. As I saw any efi.*
> > references are protected by relevant ifs but we should not do that
> > because it makes code very fragile. If somebody does not know how
> > efi symbol is created he/she may assume that it always represent
> > valid structure and do invalid references somewhere.
>
> I do not view this as a valid reason for the change.

Why?

> > Additionally, following patch adds efi struct flags member which
> > is used during runtime to differentiate between legacy BIOS and
> > EFI platforms and multiboot2 and EFI native loader. So, efi symbol
> > have to proper representation in ELF and PE Xen image. Hence,
> > define efi struct in xen/arch/x86/efi/stub.c and remove efi
> > symbol from ld script.
>
> Only this one is, afaic. The only request here would be to replace
> "following" by e.g. "a subsequent", to make the description
> independent of whether the two patches get committed together.

OK.

> > --- a/xen/arch/x86/efi/stub.c
> > +++ b/xen/arch/x86/efi/stub.c
> > @@ -8,6 +8,14 @@
> >  const bool_t efi_enabled = 0;
> >  #endif
> >
> > +struct efi __read_mostly efi = {
> > +   .acpi= EFI_INVALID_TABLE_ADDR,
> > +   .acpi20  = EFI_INVALID_TABLE_ADDR,
> > +   .mps = EFI_INVALID_TABLE_ADDR,
> > +   .smbios  = EFI_INVALID_TABLE_ADDR,
> > +   .smbios3 = EFI_INVALID_TABLE_ADDR
> > +};
>
> I don't view duplicating this here as a good approach - you'd better
> move the existing instance elsewhere. If this was a temporary thing
> (until a later patch), it might be acceptable, but since building without
> EFI support will need to remain an option (for people using older tool
> chains), I don't expect a later patch to remove this.

Do you think about separate C file which should contain efi struct
and should be included in stub.c and runtime.c? Or anything else?

Daniel

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

Re: [Xen-devel] Xen 4.8 Development Update

[Daniel Kiper]

On Tue, Jul 19, 2016 at 02:48:30PM +0100, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> = Timeline =
>
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.8 timeline are as followed:
>
> * Last posting date: September 16, 2016
> * Hard code freeze: September 30, 2016
> * RC1: TBD
> * Release: December 2, 2016
>
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.8 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
>
> RCs will be arranged immediately after freeze.
>
> = Projects =
>
> == Hypervisor ==
>
> *  Make credit2 default scheduler for Xen
>   -  Dario Faggioli

Please add:
  *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
-  Daniel Kiper

BTW, I am going to release v4 next week.

Daniel

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

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[Daniel Kiper]

On Mon, Aug 01, 2016 at 10:25:22AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 01, 2016 at 04:15:10PM +0200, Petr Tesarik wrote:
> > On Mon, 1 Aug 2016 15:47:58 +0200

[...]

> I wonder if Xen should do that - as in 'fix' the bootparams to not have it.
> Or perhaps Linux code during bootup can sanitze this..

It should but I am not sure it does. Or at least it should display warning
that dom0 crashkernel argument does not make sense and is not supported.

> > > And then trying to invoke a locally loaded crash kernel which won't
> > > work is bad
> >
> > Without actually knowing whether a PV kernel can kexec another PV
> > kernel, this discussion is somewhat moot...
> >
> > But let me repeat: if PV kexec works, then it has always had priority
> > over the hypercall. If it doesn't work, then it has always been broken.
> > For the latter case, I agree that the kernel should not even allow to
> > load the kexec image, but that's unrelated to my patch.
> >
> > Has anyone here tried booting up a PV domain and performing kexec(2)?
>
> Yes. Daniel (CC-ed) did it. He had it working but only for one CPU
> and then Greg KH picked up the patchset .. and not sure what happend.

Greg had it in https://git.kernel.org/ some time ago, however, it looks
that it vanished. Anyway, IIRC, the problem was that kdump must be started
with one processor and this is not easy due to various constraints. Later,
PV guest have to be restarted to regain full functionality.

> The underlaying issue was the PV guest could not re-initialize the grants,
> events, etc - but now with Vitaly's 'reset' hypercall it would be possible.
> Except the 'reset' hypercall is only for HVM guests.

I think that it is for PVHVM. Hence, making it work on PV should not be
very difficult. I hope...

Daniel

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

Re: [Xen-devel] [PATCH] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Daniel Kiper]

On Mon, Jul 18, 2016 at 10:01:27AM -0400, Boris Ostrovsky wrote:
> ACPI builder is currently distributed under GPLv2 license.
>
> We plan to make the builder available to components other
> than the hvmloader (which is also GPLv2). Some of these
> components (such as libxl) may be distributed under LGPL-2.1
> so that they can be used by non-GPLv2 callers.  But this
> will not be possible if we incorporate the ACPI builder in
> those other components.
>
> To avoid this problem we are relicensing sources in ACPI
> bulder directory to the Lesser GNU Public License (LGPL)
> version 2.1
>
> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
> CC: Kouya Shimura <ko...@jp.fujitsu.com>
> CC: Daniel Kiper <dki...@net-space.pl>
> CC: Stefan Berger <stef...@us.ibm.com>
> CC: Simon Horman <ho...@verge.net.au>
> CC: Keir Fraser <k...@xen.org>
> CC: Ian Jackson <ian.jack...@eu.citrix.com>
> CC: Lars Kurth <lars.ku...@citrix.com>

Acked-by: Daniel Kiper <dki...@net-space.pl>

Daniel

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

Re: [Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper]

On Fri, Apr 15, 2016 at 02:33:12PM +0200, Daniel Kiper wrote:
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and
> going down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because start lives on 1 MiB address. So, I tried to use
> mem_lower address calculated by GRUB2. However, it works only on some
> machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> which uses first ~640 KiB for boot services code or data... :-(((
>
> In case of multiboot2 protocol we need that place_string() only allocate
> memory chunk for EFI memory map. However, I think that it should be fixed
> instead of making another function used just in one case. I thought about
> two solutions.

I have done more experiments, read more code, etc. You can find results below.

> 1) We could use native EFI allocation functions (e.g. AllocatePool()
>or AllocatePages()) to get memory chunk. However, later (somewhere
>in __start_xen()) we must copy its contents to safe place or reserve
>this in e820 memory map and map it in Xen virtual address space.

I have checked Linux kernel code. It allocates buffer for memory map using
EFI API and later reserve it in e820 memory map. Simple. This should work
for us too but...

>In later case we must also care about conflicts with e.g. crash
>kernel regions which could be quite difficult.

This is not a problem since Xen can choose dynamically placement of kdump
region during boot phase and there is no requirement to specify it in boot
command line. This means that it will avoid all allocated/reserved regions
including EFI memory map. However, there is one potential problem which
cannot be avoided simply with current EFI spec. I think about conflicts
with trampoline. It must live below 1 MiB. However, there is not something
similar to "AllocateMaxAddress" option for AllocatePages() which would
ask EFI to allocate memory above a given address (Hmmm... Why UEFI designers
did not added such option, e.g. "AllocateMinAddress"? For me it is obvious
thing if we have "AllocateMaxAddress"). So, it means that we cannot simply
say "give me a memory chunk above 1 MiB". AIUI, Linux guys do not care,
hope that all EFI platforms are smart and AllocatePages() tries hard to
avoid everything below 1 MiB. We can go this way too. However, I am almost
sure that sooner or later we will find crazy platforms which allocate memory
from 0-1 MiB region. We can avoid this by getting EFI memory map, looking for
free regions above 1 MiB and then trying to allocate memory chunk using
AllocatePages() with "AllocateAddress". Does it make sense?

> 2) We may allocate memory area statically somewhere in Xen code which
>could be used as memory pool for early dynamic allocations. Looks
>quite simple. Additionally, it would not depend on EFI at all and
>could be used on legacy BIOS platforms if we need it. However, we
>must carefully choose size of this pool. We do not want increase
>Xen binary size too much and waste too much memory but also we must fit
>at least memory map on x86 EFI platforms. As I saw on small machine,
>e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
>than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
>So, it means that we need more than 8 KiB for EFI memory map only.
>Additionally, if we want to use this memory pool for Xen and modules
>command line storage (it would be used when xen.efi is executed as EFI
>application) then we should add, I think, about 1 KiB. In this case,
>to be on safe side, we should assume at least 64 KiB pool for early
>memory allocations, which is about 4 times of our earlier calculations.
>However, during discussion on Xen-devel Jan Beulich suggested that
>just in case we should use 1 MiB memory pool like it was in original
>place_string() implementation. So, let's use 1 MiB as it was proposed.
>If we think that we should not waste unallocated memory in the pool
>on running system then we can mark this region as __initdata and move
>all required data to dynamically allocated places somewhere in 
> __start_xen().

2a) We can create something like .init.bss and put this thing at the end of
regular .bss section. Then allocate memory chunks starting from lowest
address. After init phase we can free unused memory as in case of .init.text
or .init.data sections. This way we do not need allocate any space in
image file and freeing of unused memory should be simple. What do you
think about that one?

Daniel

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

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

On Fri, May 27, 2016 at 02:16:09AM -0600, Jan Beulich wrote:
> >>> On 25.05.16 at 18:45,  wrote:
> > On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >> >>> On 15.04.16 at 14:33,  wrote:
> >> > Existing solution does not allocate space for this symbol and any
> >> > references to acpi20, etc. does not make sense. As I saw any efi.*
> >> > references are protected by relevant ifs but we should not do that
> >> > because it makes code very fragile. If somebody does not know how
> >> > efi symbol is created he/she may assume that it always represent
> >> > valid structure and do invalid references somewhere.
> >>
> >> I do not view this as a valid reason for the change.
> >
> > Why?
>
> Because there are no accesses to the structure in non-EFI builds?
> Even if it's just a small table, I'm generally opposed to adding dead
> code or data. I simply do not like the attitude of "memory is cheap"
> these days. Following that model leads to quite a bit of useless
> bloat. Plus no matter whether memory is cheap, cache and TLB
> bandwidth are precious, and both may get pressure added by such
> dead elements.
>
> >> > --- a/xen/arch/x86/efi/stub.c
> >> > +++ b/xen/arch/x86/efi/stub.c
> >> > @@ -8,6 +8,14 @@
> >> >  const bool_t efi_enabled = 0;
> >> >  #endif
> >> >
> >> > +struct efi __read_mostly efi = {
> >> > +.acpi= EFI_INVALID_TABLE_ADDR,
> >> > +.acpi20  = EFI_INVALID_TABLE_ADDR,
> >> > +.mps = EFI_INVALID_TABLE_ADDR,
> >> > +.smbios  = EFI_INVALID_TABLE_ADDR,
> >> > +.smbios3 = EFI_INVALID_TABLE_ADDR
> >> > +};
> >>
> >> I don't view duplicating this here as a good approach - you'd better
> >> move the existing instance elsewhere. If this was a temporary thing
> >> (until a later patch), it might be acceptable, but since building without
> >> EFI support will need to remain an option (for people using older tool
> >> chains), I don't expect a later patch to remove this.
> >
> > Do you think about separate C file which should contain efi struct
> > and should be included in stub.c and runtime.c? Or anything else?
>
> A separate file seems to be overkill. Just move it to some other
> existing file; I'm sure some sensible place can be found.

This solution is not perfect, however, I cannot find better place for
efi struct. If you have one then drop me a line.

Daniel

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

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

On Wed, Jul 06, 2016 at 12:55:42AM -0600, Jan Beulich wrote:
> >>> On 05.07.16 at 20:33,  wrote:
> > On Fri, May 27, 2016 at 02:16:09AM -0600, Jan Beulich wrote:
> >> >>> On 25.05.16 at 18:45,  wrote:
> >> > On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >> >> >>> On 15.04.16 at 14:33,  wrote:
> >> >> > --- a/xen/arch/x86/efi/stub.c
> >> >> > +++ b/xen/arch/x86/efi/stub.c
> >> >> > @@ -8,6 +8,14 @@
> >> >> >  const bool_t efi_enabled = 0;
> >> >> >  #endif
> >> >> >
> >> >> > +struct efi __read_mostly efi = {
> >> >> > + .acpi= EFI_INVALID_TABLE_ADDR,
> >> >> > + .acpi20  = EFI_INVALID_TABLE_ADDR,
> >> >> > + .mps = EFI_INVALID_TABLE_ADDR,
> >> >> > + .smbios  = EFI_INVALID_TABLE_ADDR,
> >> >> > + .smbios3 = EFI_INVALID_TABLE_ADDR
> >> >> > +};
> >> >>
> >> >> I don't view duplicating this here as a good approach - you'd better
> >> >> move the existing instance elsewhere. If this was a temporary thing
> >> >> (until a later patch), it might be acceptable, but since building 
> >> >> without
> >> >> EFI support will need to remain an option (for people using older tool
> >> >> chains), I don't expect a later patch to remove this.
> >> >
> >> > Do you think about separate C file which should contain efi struct
> >> > and should be included in stub.c and runtime.c? Or anything else?
> >>
> >> A separate file seems to be overkill. Just move it to some other
> >> existing file; I'm sure some sensible place can be found.
> >
> > This solution is not perfect, however, I cannot find better place for
> > efi struct. If you have one then drop me a line.
>
> common/kernel.c or common/lib.c.

This means that we must delete efi struct initialization from
xen/common/efi/runtime.c and xen/arch/x86/efi/stub.c and put
it in one of both files mentioned by you. Is it OK for you?

Daniel

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

Re: [Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper]

On Wed, Jul 06, 2016 at 01:22:24AM -0600, Jan Beulich wrote:
> >>> On 05.07.16 at 20:26, <daniel.ki...@oracle.com> wrote:
> > On Fri, Apr 15, 2016 at 02:33:12PM +0200, Daniel Kiper wrote:
> >> 1) We could use native EFI allocation functions (e.g. AllocatePool()
> >>or AllocatePages()) to get memory chunk. However, later (somewhere
> >>in __start_xen()) we must copy its contents to safe place or reserve
> >>this in e820 memory map and map it in Xen virtual address space.
> >
> > I have checked Linux kernel code. It allocates buffer for memory map using
> > EFI API and later reserve it in e820 memory map. Simple. This should work
> > for us too but...
> >
> >>In later case we must also care about conflicts with e.g. crash
> >>kernel regions which could be quite difficult.
> >
> > This is not a problem since Xen can choose dynamically placement of kdump
> > region during boot phase and there is no requirement to specify it in boot
> > command line. This means that it will avoid all allocated/reserved regions
> > including EFI memory map. However, there is one potential problem which
> > cannot be avoided simply with current EFI spec. I think about conflicts
> > with trampoline. It must live below 1 MiB. However, there is not something
> > similar to "AllocateMaxAddress" option for AllocatePages() which would
> > ask EFI to allocate memory above a given address (Hmmm... Why UEFI designers
> > did not added such option, e.g. "AllocateMinAddress"? For me it is obvious
> > thing if we have "AllocateMaxAddress").
>
> Not obvious to me at all. Allowing an upper bound is natural (for
> both DMA purposes and arbitrary other addressing restrictions).
> Allowing a lower bound to be specified isn't.

I think that I have shown above that on some platforms this could be useful 
option.

> > So, it means that we cannot simply
> > say "give me a memory chunk above 1 MiB". AIUI, Linux guys do not care,
> > hope that all EFI platforms are smart and AllocatePages() tries hard to
> > avoid everything below 1 MiB. We can go this way too. However, I am almost
> > sure that sooner or later we will find crazy platforms which allocate memory
> > from 0-1 MiB region. We can avoid this by getting EFI memory map, looking 
> > for
> > free regions above 1 MiB and then trying to allocate memory chunk using
> > AllocatePages() with "AllocateAddress". Does it make sense?
>
> I don't see the point of all that, as I don't see why any EFI
> implementation would want to deviate from the first line principle
> of satisfying allocation requests as high as possible.

In general this is good idea. However, I have not seen such requirement in
UEFI spec. So, I suppose that bad things may happen on some EFI implementations
and that is why I proposed a bit "smarter" approach. On the other hand if Linux
does allocations in "simple" way (just AllocatePages() call) then it means that
this solution works on most platforms if not all. So, probably "simple" solution
would work for us too.

Anyway, I think that it is worth considering all potential issues if we are
aware of them in advance.

> Apart from that using (only) EFI allocation mechanisms for
> obtaining the trampoline area won't work anyway, as we already
> know there are systems where all of the memory below 1Mb is
> in use by EFI (mostly with boot kind allocations, i.e. becoming
> available after ExitBootServices()).

I know about that. However, I am talking here about memory allocation
for EFI memory map. As I said above this region may potentially (well,
it looks that probability is low but as I said earlier we should think
and discuss this issue here) conflict with trampoline region. Though
I am not saying how this region (for trampoline) should be allocated
because current solution works well.

> >> 2) We may allocate memory area statically somewhere in Xen code which
> >>could be used as memory pool for early dynamic allocations. Looks
> >>quite simple. Additionally, it would not depend on EFI at all and
> >>could be used on legacy BIOS platforms if we need it. However, we
> >>must carefully choose size of this pool. We do not want increase
> >>Xen binary size too much and waste too much memory but also we must fit
> >>at least memory map on x86 EFI platforms. As I saw on small machine,
> >>e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
> >>than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
> >>So, it means that we need more than 8 KiB for EFI memory map only.
>

Re: [Xen-devel] [PATCH v3 09/16] efi: explicitly define efi struct in xen/arch/x86/efi/stub.c

[Daniel Kiper]

On Wed, Jul 06, 2016 at 06:00:47AM -0600, Jan Beulich wrote:
> >>> On 06.07.16 at 12:27,  wrote:
> > On Wed, Jul 06, 2016 at 12:55:42AM -0600, Jan Beulich wrote:
> >> >>> On 05.07.16 at 20:33,  wrote:
> >> > On Fri, May 27, 2016 at 02:16:09AM -0600, Jan Beulich wrote:
> >> >> >>> On 25.05.16 at 18:45,  wrote:
> >> >> > On Wed, May 25, 2016 at 01:03:42AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 15.04.16 at 14:33,  wrote:
> >> >> >> > --- a/xen/arch/x86/efi/stub.c
> >> >> >> > +++ b/xen/arch/x86/efi/stub.c
> >> >> >> > @@ -8,6 +8,14 @@
> >> >> >> >  const bool_t efi_enabled = 0;
> >> >> >> >  #endif
> >> >> >> >
> >> >> >> > +struct efi __read_mostly efi = {
> >> >> >> > +  .acpi= EFI_INVALID_TABLE_ADDR,
> >> >> >> > +  .acpi20  = EFI_INVALID_TABLE_ADDR,
> >> >> >> > +  .mps = EFI_INVALID_TABLE_ADDR,
> >> >> >> > +  .smbios  = EFI_INVALID_TABLE_ADDR,
> >> >> >> > +  .smbios3 = EFI_INVALID_TABLE_ADDR
> >> >> >> > +};
> >> >> >>
> >> >> >> I don't view duplicating this here as a good approach - you'd better
> >> >> >> move the existing instance elsewhere. If this was a temporary thing
> >> >> >> (until a later patch), it might be acceptable, but since building 
> >> >> >> without
> >> >> >> EFI support will need to remain an option (for people using older 
> >> >> >> tool
> >> >> >> chains), I don't expect a later patch to remove this.
> >> >> >
> >> >> > Do you think about separate C file which should contain efi struct
> >> >> > and should be included in stub.c and runtime.c? Or anything else?
> >> >>
> >> >> A separate file seems to be overkill. Just move it to some other
> >> >> existing file; I'm sure some sensible place can be found.
> >> >
> >> > This solution is not perfect, however, I cannot find better place for
> >> > efi struct. If you have one then drop me a line.
> >>
> >> common/kernel.c or common/lib.c.
> >
> > This means that we must delete efi struct initialization from
> > xen/common/efi/runtime.c and xen/arch/x86/efi/stub.c and put
> > it in one of both files mentioned by you. Is it OK for you?
>
> Note how in my original reply I said "move the existing instance
> elsewhere".

OK, thanks. I will do that.

Daniel

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

[Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

[Daniel Kiper]

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |4 
 xen/include/xen/efi.h  |1 +
 5 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 71ade05..7541b91 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled(EFI_BOOT) && efi_rs_using_pgtables() )
+if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 7ce3761..b429fd0 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -119,7 +119,7 @@ void machine_halt(void)
 static void default_reboot_type(void)
 {
 if ( reboot_type == BOOT_INVALID )
-reboot_type = efi_enabled(EFI_BOOT) ? BOOT_EFI
+reboot_type = efi_enabled(EFI_RS) ? BOOT_EFI
   : acpi_disabled ? BOOT_KBD
   : BOOT_ACPI;
 }
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b2ecc8e..8d94530 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -686,7 +686,7 @@ static unsigned long get_cmos_time(void)
 static bool_t __read_mostly cmos_rtc_probe;
 boolean_param("cmos-rtc-probe", cmos_rtc_probe);
 
-if ( efi_enabled(EFI_BOOT) )
+if ( efi_enabled(EFI_RS) )
 {
 res = efi_get_time();
 if ( res )
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index edd0434..dd6b0a8 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 
 __set_bit(EFI_BOOT, );
 
+#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
+__set_bit(EFI_RS, );
+#endif
+
 efi_init(ImageHandle, SystemTable);
 
 use_cfg_file = efi_arch_use_config_file(SystemTable);
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index be18e4d..ba14472 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -12,6 +12,7 @@
 struct efi {
 unsigned long flags;/* Bit fields representing available EFI 
features/properties */
 #define EFI_BOOT   0   /* Were we booted from EFI? */
+#define EFI_RS 2   /* Can we use runtime services? */
 unsigned long mps;  /* MPS table */
 unsigned long acpi; /* ACPI table (IA64 ext 0.71) */
 unsigned long acpi20;   /* ACPI table (ACPI 2.0) */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 18/19] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1 MiB and ends at 17 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - default load address is changed from 1 MiB to 2 MiB; I did that because
initial page tables are using 2 MiB huge pages and this way required
updates for them are quite easy; it means that e.g. we avoid spacial
cases for start and end of required memory region if it live at address
not aligned to 2 MiB,
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls,
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

PS I am still not convinced that move to %fs relative addressing is good
   idea. As you can see code grows larger due to GDT initialization stuff,
   etc. However, I cannot see potential gains for now and future (probably
   it would be if whole Xen code, not early boot one, played segment registers
   games). Well, maybe in one or two places where base register is not used
   in full SIB addressing mode. So, question is: does it pay? Does gains
   overweight all efforts related to %fs games? Maybe we should stay with
   %esi relative addressing? Of course I am aware that it is not perfect.
   However, IMO, it is much simpler and clearer.
   This is my suggestion. If you agree with me I can change code once again
   and back to %esi. This is not big problem. If not I am not going to argue
   longer. I will do what you request. Well, it will be nice if you convince
   me that your idea is good and I am wrong then...  ;-)))

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |4 +-
 xen/arch/x86/Rules.mk  |4 +
 xen/arch/x86/boot/head.S   |  204 +++-
 xen/arch/x86/boot/trampoline.S |   10 +-
 xen/arch/x86/boot/wakeup.S |4 +-
 xen/arch/x86/boot/x86_64.S |   51 --
 xen/arch/x86/efi/efi-boot.h|3 +-
 xen/arch/x86/setup.c   |   31 +++---
 xen/arch/x86/xen.lds.S |8 +-
 xen/include/asm-x86/config.h   |1 +
 xen/include/asm-x86/page.h |2 +-
 11 files changed, 217 insertions(+), 105 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9464b7b..df899c1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -89,8 +89,8 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(

[Xen-devel] [PATCH v4 15/19] x86/efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move from #2 solution to #2a solution,
   - improve commit message.
---
 xen/arch/x86/efi/efi-boot.h |   58 +--
 xen/arch/x86/efi/stub.c |4 +++
 xen/arch/x86/setup.c|5 ++--
 xen/include/xen/efi.h   |1 +
 4 files changed, 58 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 1fa9e47..3f87b7c 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -103,9 +103,56 @@ static void __init relocate_trampoline(unsigned long phys)
 *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
 }
 
+#define EBMALLOC_SIZE  MB(1)
+
+static char __section(".bss.page_aligned") ebmalloc_mem[EBMALLOC_SIZE];
+static char __initdata *ebmalloc_free = NULL;
+
+/* EFI boot allocator. */
+static void __init *ebmalloc(size_t size)
+{
+void *ptr;
+
+/*
+ * Init ebmalloc_free on runtime. Static initialization
+ * will not work because it puts virtual address there.
+ */
+if ( ebmalloc_free == NULL )
+ebmalloc_free = ebmalloc_mem;
+
+ptr = ebmalloc_free;
+
+ebmalloc_free += size;
+
+if ( ebmalloc_free - ebmalloc_mem > sizeof(ebmalloc_mem) )
+blexit(L"Out of static memory\r\n");
+
+return ptr;
+}
+
+void __init free_ebmalloc_unused_mem(void)
+{
+unsigned long start, end;
+
+if ( ebmalloc_free )
+{
+start = (unsigned long)ebmalloc_free - xen_phys_start

[Xen-devel] [PATCH v4 19/19] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   19 ++-
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a1b0c05..25a92e0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offset(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -372,10 +379,19 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne 1f
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp 9f
+
+1:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
-je  trampoline_bios_setup
+je  9f
 
 /* EFI IA-32 platforms are not supported. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
@@ -389,6 +405,7 @@ __start:
 cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%ecx)
 je  trampoline_bios_setup
 
+9:
 /* Go to next Multiboot2 information tag. */
 add MB2_tag_size(%ecx),%ecx
 add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 9695ea6..022c280 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -175,6 +175,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 0f113f1..a1d355c 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS   7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE  10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED 0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED  1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS 18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH   19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH   20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
 
 /* Multiboot 2 tag alignment. */
 #define MULT

[Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions

[Daniel Kiper]

Create generic alloc and copy functions. We need
separate tools for memory allocation and copy to
provide multiboot2 protocol support.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - avoid assembly usage.

v3 - suggestions/fixes:
   - use "g" constraint instead of "r" for alloc_mem() bytes argument
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generalize new functions names
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   51 ++---
 1 file changed, 30 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 28c6cea..21b1f32 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -32,60 +32,69 @@ typedef unsigned int u32;
 
 static u32 alloc;
 
-static void *reloc_mbi_struct(void *old, unsigned int bytes)
+static u32 alloc_mem(u32 bytes)
 {
-void *new;
+return alloc -= ALIGN_UP(bytes, 16);
+}
 
-alloc -= ALIGN_UP(bytes, 16);
-new = (void *)alloc;
+static u32 copy_mem(u32 src, u32 bytes)
+{
+u32 dst, dst_ret;
+
+dst = alloc_mem(bytes);
+dst_ret = dst;
 
 while ( bytes-- )
-*(char *)new++ = *(char *)old++;
+*(char *)dst++ = *(char *)src++;
 
-return (void *)alloc;
+return dst_ret;
 }
 
-static char *reloc_mbi_string(char *old)
+static u32 copy_string(u32 src)
 {
-char *p;
-for ( p = old; *p != '\0'; p++ )
+u32 p;
+
+if ( src == 0 )
+return 0;
+
+for ( p = src; *(char *)p != '\0'; p++ )
 continue;
-return reloc_mbi_struct(old, p - old + 1);
+
+return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t __stdcall *reloc(multiboot_info_t *mbi_old, u32 trampoline)
+multiboot_info_t __stdcall *reloc(u32 mbi_old, u32 trampoline)
 {
 multiboot_info_t *mbi;
 int i;
 
 alloc = trampoline;
 
-mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+mbi = (multiboot_info_t *)copy_mem(mbi_old, sizeof(*mbi));
 
 if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
+mbi->cmdline = copy_string(mbi->cmdline);
 
 if ( mbi->flags & MBI_MODULES )
 {
-module_t *mods = reloc_mbi_struct(
-(module_t *)mbi->mods_addr, mbi->mods_count * sizeof(module_t));
+module_t *mods;
 
-mbi->mods_addr = (u32)mods;
+mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+
+mods = (module_t *)mbi->mods_addr;
 
 for ( i = 0; i < mbi->mods_count; i++ )
 {
 if ( mods[i].string )
-mods[i].string = (u32)reloc_mbi_string((char *)mods[i].string);
+mods[i].string = copy_string(mods[i].string);
 }
 }
 
 if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = (u32)reloc_mbi_struct(
-(memory_map_t *)mbi->mmap_addr, mbi->mmap_length);
+mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
 
 if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = (u32)reloc_mbi_string(
-(char *)mbi->boot_loader_name);
+mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
 mbi->flags &= (MBI_MEMLIMITS |
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 01/19] x86: allow EFI reboot method neither on EFI platforms...

[Daniel Kiper]

..nor EFI platforms with runtime services disabled.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/shutdown.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 0e1499d..3cdd4e8 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str)
 break;
 str++;
 }
+
+if ( reboot_type == BOOT_EFI && !efi_enabled(EFI_RS) )
+reboot_type = BOOT_INVALID;
 }
 custom_param("reboot", set_reboot_type);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 11/19] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi.flags. This patch only defines
EFI_BOOT feature which is equal to old efi_enabled == 1.
Subsequent patches will define EFI_LOADER and EFI_RS features
accordingly. Latter one is added to ease control on runtime
services usage.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - rename EFI_PLATFORM to EFI_BOOT
 (suggested by Jan Beulich),
   - move EFI_BOOT definition to efi struct definition
 (suggested by Jan Beulich),
   - remove unneeded efi.flags initialization
 (suggested by Jan Beulich),
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - do efi_enabled() cleanup
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message.

v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|4 
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   10 +-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |2 ++
 xen/common/efi/runtime.c   |6 --
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |   11 +--
 11 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index b049e31..8dcb640 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -696,7 +696,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_BOOT) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..71ade05 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_enabled(EFI_BOOT) && efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..3e1d1ea 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,10 +4,6 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
-
 void __init efi_init_memory(void) { }
 
 void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t l4e) { }
diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
index ef6557c..c3d5bdc 100644
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -564,7 +564,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
 
 static __init void efi_unmap_mpf(void)
 {
-   if (efi_enabled)
+   if (efi_enabled(EFI_BOOT))
clear_fixmap(FIX_EFI_MPF);
 }
 
@@ -722,7 +722,7 @@ void __init find_smp_config (void)
 {
unsigned int address;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
efi_check_config();
return;
}
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 217c775..1e8dfa5 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -438,8 +438,8 @@ static void __init parse_video_info(void)
 {
 struct boot_video_info *bvi = (boot_vid_info);
 
-/* The EFI loader fills vga_console_info directly. */
-if ( efi_enabled )
+/* vga_console_info is filled directly on EFI platform. */
+if (

[Xen-devel] [PATCH v4 03/19] x86/boot: create *.lnk files with linker script

[Daniel Kiper]

Newer GCC (e.g. gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)) does
some code optimizations by creating data sections (e.g. jump addresses
for C switch/case are calculated using data in .rodata section). This
thing is not accepted by *.lnk build recipe which requires that only .text
section lives in output. Potentially we can inhibit this GCC behavior by
using special options, e.g. -fno-tree-switch-conversion. However, this
does not guarantee that in the future new similar optimizations or anything
else which creates not accepted sections will not break our build recipes
again. I do not mention that probably this is not good idea to just disable
random optimizations. So, take over full control on *.lnk linking process
by using linker script and merge required text and data sections into one
.text section.

Additionally, remove .got.plt section which is not used in our final code.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/build32.lds |   51 +
 xen/arch/x86/boot/build32.mk  |   10 +---
 2 files changed, 58 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/boot/build32.lds

diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
new file mode 100644
index 000..b14c7d5
--- /dev/null
+++ b/xen/arch/x86/boot/build32.lds
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+ENTRY(_start)
+
+SECTIONS
+{
+  /* Merge code and data into one section. */
+  .text : {
+*(.text)
+*(.text.*)
+*(.rodata)
+  }
+
+  /DISCARD/ : {
+/*
+ * PIC/PIE executable contains .got.plt section even
+ * if it is not linked with dynamic libraries. In such
+ * case it is just placeholder for _GLOBAL_OFFSET_TABLE_
+ * symbol and .PLT0. .PLT0 is filled by dynamic linker
+ * and our code is not supposed to be loaded by dynamic
+ * linker. So, from our point of view .PLT0 is unused.
+ * This means that there is pretty good chance that
+ * we can safely drop .got.plt as a whole here. Sadly
+ * this is not true. _GLOBAL_OFFSET_TABLE_ is used as
+ * a reference for relative addressing (and only for
+ * that thing) and ld complains if we remove .got.plt
+ * section here because it cannot find required symbol.
+ * However, _GLOBAL_OFFSET_TABLE_ is no longer needed
+ * in final output. So, drop .got.plt section during
+ * conversion to plain binary format.
+ *
+ * Please check build32.mk for more details.
+ */
+/* *(.got.plt) */
+  }
+}
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index 4a7d388..eb02b4b 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -12,20 +12,24 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
(od -v -t x $< | tr -s ' ' | awk 'NR > 1 {print s} {s=$$0}' | \
sed 's/ /,0x/g' | sed 's/,0x$$//' | sed 's/^[0-9]*,/ .long /') >$@
 
+#
+# Drop .got.plt during conversion to plain binary format.
+# Please check build32.lds for more details.
+#
 %.bin: %.lnk
-   $(OBJCOPY) -O binary $< $@
+   $(OBJCOPY) -O binary -R .got.plt $< $@
 
 %.lnk: %.o
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.rodata.*|.bss|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
esac; \
done
-   $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0 -o $@ $<
+   $(LD) $(LDFLAGS_DIRECT) -N -T build32.lds -o $@ $<
 
 %.o: %.c
$(CC) $(CFLAGS) -c -fpic $< -o $@
-- 
1.7.10.4

[Xen-devel] [PATCH v4 07/19] x86/boot: use %ecx instead of %eax

[Daniel Kiper]

Use %ecx instead of %eax to store low memory upper limit from EBDA.
This way we do not wipe multiboot protocol identifier. It is needed
in reloc() to differentiate between multiboot (v1) and
multiboot2 protocol.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
 xen/arch/x86/boot/head.S |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 7e5ae12..ffafcb5 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -87,14 +87,14 @@ __start:
 jne not_multiboot
 
 /* Set up trampoline segment 64k below EBDA */
-movzwl  0x40e,%eax  /* EBDA segment */
-cmp $0xa000,%eax/* sanity check (high) */
+movzwl  0x40e,%ecx  /* EBDA segment */
+cmp $0xa000,%ecx/* sanity check (high) */
 jae 0f
-cmp $0x4000,%eax/* sanity check (low) */
+cmp $0x4000,%ecx/* sanity check (low) */
 jae 1f
 0:
-movzwl  0x413,%eax  /* use base memory size on failure */
-shl $10-4,%eax
+movzwl  0x413,%ecx  /* use base memory size on failure */
+shl $10-4,%ecx
 1:
 /*
  * Compare the value in the BDA with the information from the
@@ -106,20 +106,20 @@ __start:
 cmp $0x100,%edx /* is the multiboot value too small? */
 jb  2f  /* if so, do not use it */
 shl $10-4,%edx
-cmp %eax,%edx   /* compare with BDA value */
-cmovb   %edx,%eax   /* and use the smaller */
+cmp %ecx,%edx   /* compare with BDA value */
+cmovb   %edx,%ecx   /* and use the smaller */
 
 2:  /* Reserve 64kb for the trampoline */
-sub $0x1000,%eax
+sub $0x1000,%ecx
 
 /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
-xor %al, %al
-shl $4, %eax
-mov %eax,sym_phys(trampoline_phys)
+xor %cl, %cl
+shl $4, %ecx
+mov %ecx,sym_phys(trampoline_phys)
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%eax/* Boot trampoline address. */
+push%ecx/* Boot trampoline address. */
 push%ebx/* Multiboot information address. */
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 00/19] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending fourth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes:
  - new patches: 01, 02, 04, 12, 13,
  - changed patches: 03, 05, 06, 08, 09, 10, 11, 14, 15, 16, 17, 18, 19.

This patch series was build with following tools:
  - gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
and binutils 2.17-3+etch1,
  - gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)
and binutils 2.23.2-2.el6,
  - gcc version 4.7.2 (Debian 4.7.2-5)
and binutils 2.22-8,
  - gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
and binutils 2.25-9.fc22.

I hope that features provided by this patch series will be included
in Xen 4.8 release in one way or another.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

PS FYI, I will be on vacation in August 6-15 and 20-28.
   It will be nice if you review my patches during that time.

 .gitignore|5 +-
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |4 +
 xen/arch/x86/boot/Makefile|   10 +-
 xen/arch/x86/boot/build32.lds |   53 
 xen/arch/x86/boot/build32.mk  |   12 +-
 xen/arch/x86/boot/cmdline.S   |  367 
-
 xen/arch/x86/boot/cmdline.c   |  376 
++
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  568 
+-
 xen/arch/x86/boot/reloc.c |  246 
 xen/arch/x86/boot/trampoline.S|   22 +++-
 xen/arch/x86/boot/video.S |6 -
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   51 +++-
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   11 +-
 xen/arch/x86/efi/efi-boot.h   |  108 ++--
 xen/arch/x86/efi/stub.c   |   30 -
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   48 +++
 xen/arch/x86/shutdown.c   |5 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   12 ++
 xen/arch/x86/xen.lds.S|   14 +-
 xen/common/efi/boot.c |   31 -
 xen/common/efi/runtime.c  |   20 +--
 xen/common/lib.c  |   10 +-
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/config.h  |1 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |   14 +-
 xen/include/xen/multiboot2.h  |  182 ++
 34 files changed, 1619 insertions(+), 618 deletions(-)

Daniel Kiper (19):
  x86: allow EFI reboot method neither on EFI platforms...
  x86/boot: remove multiboot1_header_end from symbol table
  x86/boot: create *.lnk files with linker script
  x86/boot/reloc: reduce assembly usage as much as possible
  x86/boot: call reloc() using stdcall calling convention
  x86/boot/reloc: create generic alloc and copy functions
  x86/boot: use %ecx instead of %eax
  x86/boot/reloc: Rename some variables and rearrange code a bit
  x86: add multiboot2 protocol support
  efi: move efi struct initialization to xen/common/lib.c
  efi: create efi_enabled()
  efi: introduce EFI_RS to ease control on runtime services usage
  efi: EFI_RS bit in efi.flags must be controlled by efi=[no-]rs command 
line argument
  efi: build xen.gz with EFI code
  x86/efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: make Xen early boot code relocatable
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v4 02/19] x86/boot: remove multiboot1_header_end from symbol table

[Daniel Kiper]

Its visibility is not needed and just pollute symbol table.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/boot/head.S |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 85770e8..e34351c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -32,7 +32,7 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   MULTIBOOT_HEADER_FLAGS
 /* Checksum: must be the negated sum of the first two fields. */
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
-multiboot1_header_end:
+.Lmultiboot1_header_end:
 
 .section .init.rodata, "a", @progbits
 .align 4
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 05/19] x86/boot: call reloc() using stdcall calling convention

[Daniel Kiper]

Current reloc() call method makes confusion and does not scale
well for more arguments. And patch adding multiboot2 protocol
support have to pass 3 arguments instead of 2. Hence, move reloc()
call to stdcall calling convention. This way, in comparison to
cdecl calling convention, we do not need to remove arguments from
stack in xen/arch/x86/boot/head.S assembly file too.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - simplify assembly in xen/arch/x86/boot/reloc.c file
 (suggested by Jan Beulich),
   - reorder arguments for reloc() call from xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |3 ++-
 xen/arch/x86/boot/reloc.c |   11 ++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index e34351c..7e5ae12 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -119,7 +119,8 @@ __start:
 
 /* Save the Multiboot info struct (after relocation) for later use. */
 mov $sym_phys(cpu0_stack)+1024,%esp
-push%ebx
+push%eax/* Boot trampoline address. */
+push%ebx/* Multiboot information address. */
 callreloc
 mov %eax,sym_phys(multiboot_ptr)
 
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 9ae42e2..28c6cea 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -10,15 +10,16 @@
  *Keir Fraser <k...@xen.org>
  */
 
-/* entered with %eax = BOOT_TRAMPOLINE */
+/*
+ * This entry point is entered from xen/arch/x86/boot/head.S with:
+ *   - 0x4(%esp) = MULTIBOOT_INFORMATION_ADDRESS,
+ *   - 0x8(%esp) = BOOT_TRAMPOLINE_ADDRESS.
+ */
 asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
-"push %eax \n"
-"push 0x8(%esp)\n"
-"call reloc\n"
-"ret  $0x4 \n"
+"jmp  reloc\n"
 );
 
 typedef unsigned int u32;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 13/19] efi: EFI_RS bit in efi.flags must be controlled by efi=[no-]rs command line argument

[Daniel Kiper]

Otherwise efi_enabled(EFI_RS) check is unreliable.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/common/efi/boot.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index dd6b0a8..95cb25f 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1159,7 +1159,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
*SystemTable)
 
 #ifndef CONFIG_ARM /* TODO - runtime service support */
 
-static bool_t __initdata efi_rs_enable = 1;
 static bool_t __initdata efi_map_uc;
 
 static void __init parse_efi_param(char *s)
@@ -1177,7 +1176,10 @@ static void __init parse_efi_param(char *s)
 *ss = '\0';
 
 if ( !strcmp(s, "rs") )
-efi_rs_enable = val;
+{
+if ( !val )
+__clear_bit(EFI_RS, );
+}
 else if ( !strcmp(s, "attr=uc") )
 efi_map_uc = val;
 
@@ -1260,7 +1262,7 @@ void __init efi_init_memory(void)
desc->PhysicalStart, desc->PhysicalStart + len - 1,
desc->Type, desc->Attribute);
 
-if ( !efi_rs_enable ||
+if ( !efi_enabled(EFI_RS) ||
  (!(desc->Attribute & EFI_MEMORY_RUNTIME) &&
   (!map_bs ||
(desc->Type != EfiBootServicesCode &&
@@ -1334,7 +1336,7 @@ void __init efi_init_memory(void)
 }
 }
 
-if ( !efi_rs_enable )
+if ( !efi_enabled(EFI_RS) )
 {
 efi_fw_vendor = NULL;
 return;
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 16/19] x86: add multiboot2 protocol support for EFI platforms

[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 <daniel.ki...@oracle.com>
---
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  |  243 ++---
 xen/arch/x86/efi/efi-boot.h   |   49 +++-
 xen/arch/x86/efi/stub.c   |   24 
 xen/arch/x86/setup.c  |8 +-
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   12 ++
 xen/include/xen/efi.h |1 +
 8 files changed, 319 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 5e61854..aca5370 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,19 +107,45 @@ 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
+
+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!"
+.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 0f
 not_multiboot:
 mov $(sym_phys(.Lbad_ldr_msg)),%esi # Error message
-print_err:
-mov $0xB8000,%edi  # VGA framebuffer
+jmp 0f
+mb2_no_st:
+mov $(sym_phys(.Lbad_ldr_nst)),%esi # Error message
+jmp 0f
+mb2_no_ih:
+mov $(sym_phys(.Lbad_ldr_nih)),%esi # Error message
+jmp 0f
+mb2_no_bs:
+mov $(sym_phys(.Lbad_ldr_nbs)),%esi # Error message
+xor %edi,%edi   # No VGA text buffer
+jmp 1f
+mb2_efi_ia_32:
+mov $(sym_phys(.Lbad_efi_msg)),%esi # Error message
+xor

[Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   11 +++
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |6 ++
 4 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b18f033..71ec34e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -211,7 +211,7 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..2a7d3e5 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,14 +1,9 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
+efi := $(if $(efi),$(shell rm disabled)y)
 
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
-
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 95cb25f..884d818 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1248,6 +1248,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 900c011..7a1bfc6 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -158,6 +158,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
 {
 unsigned int i, n;
 
+if ( !efi_enabled(EFI_BOOT) )
+return -ENOSYS;
+
 switch ( idx )
 {
 case XEN_FW_EFI_VERSION:
@@ -292,6 +295,9 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *op)
 EFI_STATUS status = EFI_NOT_STARTED;
 int rc = 0;
 
+if ( !efi_enabled(EFI_RS) )
+return -ENOSYS;
+
 switch ( op->function )
 {
 case XEN_EFI_get_time:
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 17/19] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Suggested-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich),
   - define bool_t and use it properly
 (suggested by Jan Beulich),
   - put list of delimiter chars into
 static const char[]
 (suggested by Jan Beulich),
   - use strlen() instead of strlen_opt()
 (suggested by Jan Beulich),
   - change strtoi() to strtoui() and
 optimize it a bit
 (suggested by Jan Beulich),
   - define strchr() and use it in strtoui()
 (suggested by Jan Beulich),
   - optimize vga_parse()
 (suggested by Jan Beulich),
   - move !cmdline check from assembly to C
 (suggested by Jan Beulich),
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |7 +-
 xen/arch/x86/boot/build32.lds  |1 +
 xen/arch/x86/boot/build32.mk   |4 +-
 xen/arch/x86/boot/cmdline.S|  367 ---
 xen/arch/x86/boot/cmdline.c|  376 
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |8 +
 xen/arch/x86/boot/trampoline.S |   12 ++
 xen/arch/x86/boot/video.S  |6 -
 11 files changed, 410 insertions(+), 381 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c

diff --git a/.gitignore b/.gitignore
index 9b8dece..a82f617 100644
--- a/.gitignore
+++ b/.gitignore
@@ -247,9 +247,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 71ec34e..9464b7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -212,6 +212,6 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..d73cc76 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,14 @@
 obj-bin-y += head.o
 
+CMDLINE_DEPS = video.h
+
 RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
 $(BASEDIR)/include/xen/multiboot2.h
 
-head.o: reloc.S
+head.o: cmdline.S reloc.S
+
+cmdline.S: cmdline.c $(CMDLINE_DEPS)
+   $(MAKE) -f build32.mk $@ CMDLINE_DEPS="$(CMDLINE_DEPS)"
 
 reloc.S: reloc.c $(RELOC_DEPS)
$(MAKE) -f build32.mk $@ RELOC_DEPS="$(RELOC_DEPS)"
diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
index a658ca8..c3f8825 100644
--- a/xen/arch/x86/boot/build32.lds
+++ b/xen/arch/x86/boot/build32.lds
@@ -24,6 +24,7 @@ SECTIONS
 *(.text)
 *(.text.*)
 *(.rodata)
+*(.rodata.*)
 *(.bss)
   }
 
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index d54d259..a196802 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -23,7 +23,7 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata.*|.bss.*)

[Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c |  141 +--
 xen/arch/x86/x86_64/asm-offsets.c |9 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 419 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h
+RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 
$(BASEDIR)/include/xen/multiboot.h \
+$(BASEDIR)/include/xen/multiboot2.h
 
 head.o: reloc.S
 
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index ffafcb5..5e61854 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,28 @@
 #define BOOT_PSEUDORM_CS 0x0020
 #define BOOT_PSEUDORM_DS 0x0028
 
+#define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
+#define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
+
+.macro mb2ht_args arg:req, args:vararg
+.long \arg
+.ifnb \args
+mb2ht_args \args
+.endif
+.endm
+
+.macro mb2ht_init type:req, req:req, args:vararg
+.align MULTIBOOT2_TAG_ALIGN
+.Lmb2ht_init_start\@:
+.short \type
+.short \req
+.long .Lmb2ht_init_end\@ - .Lmb2ht_init_start\@
+.ifnb \args
+mb2ht_args \args
+.endif
+.Lmb2ht_init_end\@:
+.endm
+
 ENTRY(start)
 jmp __start
 
@@ -34,6 +57,42 @@ multiboot1_header_start:   /*** MULTIBOOT1 HEADER /
 .long   -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
 .Lmultiboot1_header_end:
 
+/*** MULTIBOOT2 HEADER /
+/* Some ideas are taken from grub-2.0

[Xen-devel] [PATCH v4 08/19] x86/boot/reloc: Rename some variables and rearrange code a bit

[Daniel Kiper]

Replace mbi with mbi_out and mbi_old with mbi_in and rearrange code
a bit to make it more readable. Additionally, this way multiboot (v1)
protocol implementation and future multiboot2 protocol implementation
will use the same variable naming convention.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move to stdcall calling convention.

v3 - suggestions/fixes:
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - extract this change from main mutliboot2
 protocol implementation
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/reloc.c |   39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 21b1f32..dc6a435 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -63,45 +63,46 @@ static u32 copy_string(u32 src)
 return copy_mem(src, p - src + 1);
 }
 
-multiboot_info_t __stdcall *reloc(u32 mbi_old, u32 trampoline)
+multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 trampoline)
 {
-multiboot_info_t *mbi;
 int i;
+multiboot_info_t *mbi_out;
 
 alloc = trampoline;
 
-mbi = (multiboot_info_t *)copy_mem(mbi_old, sizeof(*mbi));
+mbi_out = (multiboot_info_t *)copy_mem(mbi_in, sizeof(*mbi_out));
 
-if ( mbi->flags & MBI_CMDLINE )
-mbi->cmdline = copy_string(mbi->cmdline);
+if ( mbi_out->flags & MBI_CMDLINE )
+mbi_out->cmdline = copy_string(mbi_out->cmdline);
 
-if ( mbi->flags & MBI_MODULES )
+if ( mbi_out->flags & MBI_MODULES )
 {
 module_t *mods;
 
-mbi->mods_addr = copy_mem(mbi->mods_addr, mbi->mods_count * 
sizeof(module_t));
+mbi_out->mods_addr = copy_mem(mbi_out->mods_addr,
+  mbi_out->mods_count * sizeof(module_t));
 
-mods = (module_t *)mbi->mods_addr;
+mods = (module_t *)mbi_out->mods_addr;
 
-for ( i = 0; i < mbi->mods_count; i++ )
+for ( i = 0; i < mbi_out->mods_count; i++ )
 {
 if ( mods[i].string )
 mods[i].string = copy_string(mods[i].string);
 }
 }
 
-if ( mbi->flags & MBI_MEMMAP )
-mbi->mmap_addr = copy_mem(mbi->mmap_addr, mbi->mmap_length);
+if ( mbi_out->flags & MBI_MEMMAP )
+mbi_out->mmap_addr = copy_mem(mbi_out->mmap_addr, 
mbi_out->mmap_length);
 
-if ( mbi->flags & MBI_LOADERNAME )
-mbi->boot_loader_name = copy_string(mbi->boot_loader_name);
+if ( mbi_out->flags & MBI_LOADERNAME )
+mbi_out->boot_loader_name = copy_string(mbi_out->boot_loader_name);
 
 /* Mask features we don't understand or don't relocate. */
-mbi->flags &= (MBI_MEMLIMITS |
-   MBI_CMDLINE |
-   MBI_MODULES |
-   MBI_MEMMAP |
-   MBI_LOADERNAME);
+mbi_out->flags &= (MBI_MEMLIMITS |
+   MBI_CMDLINE |
+   MBI_MODULES |
+   MBI_MEMMAP |
+   MBI_LOADERNAME);
 
-return mbi;
+return mbi_out;
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 04/19] x86/boot/reloc: reduce assembly usage as much as possible

[Daniel Kiper]

Next patch will leave just required jmp instruction
in xen/x86/boot/reloc.c.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
 xen/arch/x86/boot/build32.lds |1 +
 xen/arch/x86/boot/build32.mk  |2 +-
 xen/arch/x86/boot/reloc.c |   52 -
 3 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds
index b14c7d5..a658ca8 100644
--- a/xen/arch/x86/boot/build32.lds
+++ b/xen/arch/x86/boot/build32.lds
@@ -24,6 +24,7 @@ SECTIONS
 *(.text)
 *(.text.*)
 *(.rodata)
+*(.bss)
   }
 
   /DISCARD/ : {
diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
index eb02b4b..d54d259 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -23,7 +23,7 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$$name" in \
-   .data|.data.*|.rodata.*|.bss|.bss.*) \
+   .data|.data.*|.rodata.*|.bss.*) \
test $$sz != 0 || continue; \
echo "Error: non-empty $$name: 0x$$sz" >&2; \
exit $$(expr $$idx + 1);; \
diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index 63045c0..9ae42e2 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -15,39 +15,33 @@ asm (
 ".text \n"
 ".globl _start \n"
 "_start:   \n"
-"call 1f   \n"
-"1:  pop  %ebx \n"
-"mov  %eax,alloc-1b(%ebx)  \n"
-"jmp  reloc\n"
-);
-
-/*
- * This is our data. Because the code must be relocatable, no BSS is
- * allowed. All data is accessed PC-relative with inline assembly.
- */
-asm (
-"alloc:\n"
-".long 0   \n"
+"push %eax \n"
+"push 0x8(%esp)\n"
+"call reloc\n"
+"ret  $0x4 \n"
 );
 
 typedef unsigned int u32;
 #include "../../../include/xen/multiboot.h"
 
+#define __stdcall  __attribute__((__stdcall__))
+
+#define ALIGN_UP(arg, align) \
+(((arg) + (align) - 1) & ~((typeof(arg))(align) - 1))
+
+static u32 alloc;
+
 static void *reloc_mbi_struct(void *old, unsigned int bytes)
 {
 void *new;
-asm(
-"call 1f  \n"
-"1:  pop  %%edx   \n"
-"mov  alloc-1b(%%edx),%0  \n"
-"sub  %1,%0   \n"
-"and  $~15,%0 \n"
-"mov  %0,alloc-1b(%%edx)  \n"
-"mov  %0,%%edi\n"
-"rep  movsb   \n"
-   : "=" (new), "+c" (bytes), "+S" (old)
-   : : "edx", "edi", "memory");
-return new;
+
+alloc -= ALIGN_UP(bytes, 16);
+new = (void *)alloc;
+
+while ( bytes-- )
+*(char *)new++ = *(char *)old++;
+
+return (void *)alloc;
 }
 
 static char *reloc_mbi_string(char *old)
@@ -58,11 +52,15 @@ static char *reloc_mbi_string(char *old)
 return reloc_mbi_struct(old, p - old + 1);
 }
 
-multiboot_info_t *reloc(multiboot_info_t *mbi_old)
+multiboot_info_t __stdcall *reloc(multiboot_info_t *mbi_old, u32 trampoline)
 {
-multiboot_info_t *mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+multiboot_info_t *mbi;
 int i;
 
+alloc = trampoline;
+
+mbi = reloc_mbi_struct(mbi_old, sizeof(*mbi));
+
 if ( mbi->flags & MBI_CMDLINE )
 mbi->cmdline = (u32)reloc_mbi_string((char *)mbi->cmdline);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c

[Daniel Kiper]

A subsequent patch adds efi struct flags member which is used
during runtime to differentiate between legacy BIOS and EFI
platforms and multiboot2 and EFI native loader. So, efi symbol
have to proper representation in ELF and PE Xen image. Hence,
move efi struct initialization to xen/common/lib.c and remove
efi symbol from ld script.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v4 - suggestions/fixes:
   - move efi struct initialization to xen/common/lib.c
 and drop one from xen/arch/x86/efi/stub.c
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/xen.lds.S   |2 --
 xen/common/efi/runtime.c |8 
 xen/common/lib.c |   10 +-
 3 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 0970299..b1b15b7 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -265,8 +265,6 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
   /* Sections to be discarded */
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index c256814..82c45bc 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -43,14 +43,6 @@ UINT64 __read_mostly efi_boot_max_var_store_size;
 UINT64 __read_mostly efi_boot_remain_var_store_size;
 UINT64 __read_mostly efi_boot_max_var_size;
 
-struct efi __read_mostly efi = {
-   .acpi   = EFI_INVALID_TABLE_ADDR,
-   .acpi20 = EFI_INVALID_TABLE_ADDR,
-   .mps= EFI_INVALID_TABLE_ADDR,
-   .smbios = EFI_INVALID_TABLE_ADDR,
-   .smbios3 = EFI_INVALID_TABLE_ADDR,
-};
-
 const struct efi_pci_rom *__read_mostly efi_pci_roms;
 
 #ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
diff --git a/xen/common/lib.c b/xen/common/lib.c
index ae0bbb3..32f21e2 100644
--- a/xen/common/lib.c
+++ b/xen/common/lib.c
@@ -1,4 +1,4 @@
-
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +32,14 @@ const unsigned char _ctype[] = {
 _L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,   /* 224-239 */
 _L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};  /* 240-255 */
 
+struct efi __read_mostly efi = {
+   .acpi= EFI_INVALID_TABLE_ADDR,
+   .acpi20  = EFI_INVALID_TABLE_ADDR,
+   .mps = EFI_INVALID_TABLE_ADDR,
+   .smbios  = EFI_INVALID_TABLE_ADDR,
+   .smbios3 = EFI_INVALID_TABLE_ADDR,
+};
+
 /*
  * A couple of 64 bit operations ported from FreeBSD.
  * The code within the '#if BITS_PER_LONG == 32' block below, and no other
-- 
1.7.10.4


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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Daniel Kiper]

On Thu, Jul 28, 2016 at 11:25:42AM -0700, li...@ssl-mail.com wrote:
> > Hmmm Could you provide full console dump from Xen and Linux kernel?
>
> Will serial console output with these options
>
>   kernel: earlyprintk=xen,keep debug loglevel=8
>   hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring
>
> do?

I think that you should add to above mentioned hypervisor command line
at least "com1=115200,8n1 console=com1". Of course this is an example.
You should find your serial port details and configure it properly.

Daniel

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

[Daniel Kiper]

On Wed, Jul 27, 2016 at 09:09:52PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > Sadly not.  The debug symbols need to be specific to the exact binary
> > > > you booted.
> > > >
> > > > Any change in the compilation will result in the translation being
> > > > useless.  What addr2line is doing is saying "which specific bit of
> > > > source code did the compiler/linker end up putting at $X".
> > >
> > > Got it.  Weird that they don't put the .debuginfo rpms in there.  While I 
> > > was searching around kernel bug reports over at the distro there's lots 
> > > of posts telling people to debug.  Not sure then how you do it without 
> > > the debug symbols.
> > >
> > > Guess you have to build your own kernel.
> >
> > I got my hands on a 'matched set'
> >
> > rpm -qa kernel-default\*
> > kernel-default-4.7.0-5.1.x86_64
> > kernel-default-devel-4.7.0-5.1.x86_64
> > kernel-default-debuginfo-4.7.0-5.1.x86_64
> >
> > reboot to Xen, still crashes
> >
> > (XEN) [2016-07-28 00:13:18] [ Xen-4.7.0_08-452  x86_64  
> > debug=n  Tainted:C ]
> > (XEN) [2016-07-28 00:13:18] CPU:0
> > >>> (XEN) [2016-07-28 00:13:18] RIP:e033:[]
> > (XEN) [2016-07-28 00:13:18] RFLAGS: 0246   EM: 1   
> > CONTEXT: pv guest (d0v0)
> > (XEN) [2016-07-28 00:13:18] rax:    rbx: 
> >    rcx: 00016f144000
> > (XEN) [2016-07-28 00:13:18] rdx: 0001   rsi: 
> > 00016f144000   rdi: f000
> > (XEN) [2016-07-28 00:13:18] rbp: 0100   rsp: 
> > 81e03e50   r8:  81efb0c0
> > (XEN) [2016-07-28 00:13:18] r9:     r10: 
> >    r11: 0001
> > (XEN) [2016-07-28 00:13:18] r12:    r13: 
> >    r14: 81e03f28
> > (XEN) [2016-07-28 00:13:18] r15:    cr0: 
> > 80050033   cr4: 001526e0
> > (XEN) [2016-07-28 00:13:18] cr3: 000841e06000   cr2: 
> > 0018
> > (XEN) [2016-07-28 00:13:18] ds:    es:    fs:    
> > gs:    ss: e02b   cs: e033
> > (XEN) [2016-07-28 00:13:18] Guest stack trace from 
> > rsp=81e03e50:
> >
> > check ar the RIP addr
> >
> > addr2line -e /usr/lib/debug/boot/vmlinux-4.7.0-5-default.debug 
> > 81f63eb0
> > 
> > /usr/src/debug/kernel-default-4.7.0/linux-4.7/linux-obj/../arch/x86/platform/efi/efi.c:123
> >
> > in source
> >
> > @ 
> > https://github.com/torvalds/linux/blob/v4.7/arch/x86/platform/efi/efi.c
> >
> > ...
> > void __init efi_find_mirror(void)
> > {
> > efi_memory_desc_t *md;
> > u64 mirror_size = 0, total_size = 0;
> >
> > for_each_efi_memory_desc(md) {
> > unsigned long long start = md->phys_addr;
> > 123 unsigned long long size = md->num_pages << 
> > EFI_PAGE_SHIFT;
> >
> > total_size += size;
> > if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
> > memblock_mark_mirror(start, size);
> > mirror_size += size;
> > }
> > }
> > if (mirror_size)
> > pr_info("Memory: %lldM/%lldM mirrored memory\n",
> > mirror_size>>20, total_size>>20);
> > }
> > ...
> >
>
> +CC-ing Daniel.

Hmmm Could you provide full console dump from Xen and Linux kernel?

Daniel

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

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

[Daniel Kiper]

On Mon, Jul 04, 2016 at 12:33:17PM +0200, Juergen Gross wrote:
> On 12/05/16 07:35, Juergen Gross wrote:
> > Gentle ping...
>
> Okay, now 4 months since posting the last version. Could it please be
> included in a more timely manner?

Juergen and others, please be patient a bit longer. GNU, current maintainer,
others and I are working on improving GRUB2 maintenance. It will take some
time (2-4 weeks). We will drop more info when everything is established.

Stay tuned...

Daniel

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

Re: [Xen-devel] [PATCH v14 0/9] x86: multiboot2 protocol support

[Daniel Kiper]

On Thu, Feb 02, 2017 at 04:27:24PM -0600, Doug Goldstein wrote:
> On 2/2/17 4:01 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending fourteenth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
> >
> > The final goal is xen.efi binary file which could be loaded by EFI
> > loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> > multiboot2 protocol. This way we will have:
> >   - smaller Xen code base,
> >   - one code base for xen.gz and xen.efi,
> >   - one build method for xen.gz and xen.efi;
> > xen.efi will be extracted from xen(-syms)
> > file using objcopy or special custom tool,
> >   - xen.efi build will not so strongly depend
> > on a given GCC and binutils version.
> >
> > Here is short list of changes since v13:
> >   - changed patches: 2, 4.
>
> Want to make diffs of the diffs like last time? I know Jan and I
> appreciated that and it made it easier to review.

Posted!

By the way, I am traveling until Monday, so, expect some delays.

Daniel

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

[Xen-devel] [PATCH v14 1/9] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
Tested-by: Doug Goldstein <car...@cardoe.com>
---
v13 - suggestions/fixes:
- add Emacs file-local variables
  (suggested by Andrew Cooper).

v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
  (suggested by Doug Goldstein).

v9 - suggestions/fixes:
   - use .L label instead of numeric one in multiboot2 data scanning loop;
 I hope that this change does not invalidate Jan's Reviewed-by
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use sizeof(/) instead of sizeof()
 if it is possible
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
 (suggested by Jan Beulich),
   - initialize mbi_out->flags using "|=" instead of "="
 (suggested by Jan Beulich),
   - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
 if it makes sense
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - do not index mbi_out_mods[] beyond its end
 (suggested by Andrew Cooper),
   - reduce number of casts
 (suggested by Andrew Cooper and Jan Beulich),
   - add braces to increase code readability
 (suggested by Andrew Cooper).

v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c | 

[Xen-devel] [PATCH v14 6/9] x86/setup: use XEN_IMG_OFFSET instead of...

[Daniel Kiper]

..calculating its value during runtime.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
---
 xen/arch/x86/setup.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 l4_pgentry_t *pl4e;
 l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
-uint64_t load_start;
 int i, j, k;
 
 /* Select relocation address. */
@@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * with a barrier(). After this we must *not* modify static/global
  * data until after we have switched to the relocated pagetables!
  */
-load_start = (unsigned long)_start - XEN_VIRT_START;
 barrier();
-move_memory(e + load_start, load_start, _end - _start, 1);
+move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
 
 /* Walk initial pagetables, relocating page directory entries. */
 pl4e = __va(__pa(idle_pg_table));
-- 
1.7.10.4


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

[Xen-devel] [PATCH v14 3/9] efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Julien Grall <julien.gr...@arm.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
Tested-by: Doug Goldstein <car...@cardoe.com>
---
v11 - suggestions/fixes:
- #ifdef only EBMALLOC_SIZE from ebmalloc machinery
  (suggested by Jan Beulich).

v10 - suggestions/fixes:
- remove unneeded ARM free_ebmalloc_unused_mem() stub.

v9 - suggestions/fixes:
   - call free_ebmalloc_unused_mem() from efi_init_memory()
 instead of xen/arch/arm/setup.c:init_done()
 (suggested by Jan Beulich),
   - improve comments.

v8 - suggestions/fixes:
   - disable whole ebmalloc machinery on ARM platforms,
   - add comment saying what should be done before
 enabling ebmalloc on ARM,
 (suggested by Julien Grall),
   - move ebmalloc code before efi-boot.h inclusion and
 remove unneeded forward declaration
 (suggested by Jan Beulich),
   - remove free_ebmalloc_unused_mem() call from
 xen/arch/arm/setup.c:init_done()
 (suggested by Julien Grall),
   - improve commit message.

v7 - suggestions/fixes:
   - enable most of ebmalloc machinery on ARM platforms
 (suggested by Jan Beulich),
   - remove unneeded cast
 (suggested by Jan Beulich),
   - wrap long line
 (suggested by Jan Beulich),
   - improve commit message.

v6 - suggestions/fixes:
  

[Xen-devel] [PATCH v14 8/9] x86/boot: rename sym_phys() to sym_offs()

[Daniel Kiper]

This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.

There is no functional change.

Suggested-by: Jan Beulich <jbeul...@suse.com>
Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
---
v8 - suggestions/fixes:
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S   |   38 +++---
 xen/arch/x86/boot/trampoline.S |2 +-
 xen/arch/x86/boot/wakeup.S |4 ++--
 xen/arch/x86/boot/x86_64.S |   18 +-
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 156518c..a1f69c0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym)  sym_phys(sym)(%esi)
-#define sym_fs(sym)   %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_offs(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_offs(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
 
 /* EFI64 Multiboot2 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_mb2_start)
+   sym_offs(__efi64_mb2_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -119,7 +119,7 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   7*8-1
 gdt_boot_base:
-.long   sym_phys(trampoline_gdt)
+.long   sym_offs(trampoline_gdt)
 .long   0 /* Needed for 64-bit lgdt */
 
 vga_text_buffer:
@@ -131,23 +131,23 @@ efi_platform:
 .section .init.text, "ax", @progbits
 
 bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi   # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi   # Error message
 jmp .Lget_vtb
 not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi   # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi   # Error message
+add $sym_offs(.Lbad_efi_msg),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lget_vtb:
@@ -358,7 +358,7 @@ __start:
 cli
 
 /* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
 
 /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
 xor %edx,%edx
@@ -530,8 +530,8 @@ trampoline_setup:
 jnz 1f
 
 /* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
 push%fs
 pop %es
 sub %edi,%ecx
@@ -604,22 +604,22 @@ trampoline_setup:
 
 /* Apply relocations to bootstrap trampoline. */
 mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
 1:
 mov %fs:(%edi),%eax
 add %edx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
 jb  1b
 
 /* Patch in the trampoline segment. */
 shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
 1:
 mov %fs:(%edi),%eax
 mov %dx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
 jb  1b
 
 /* Do not parse command line on EFI platform here. */
@@ -645,7 +645,7 @@ trampoline_setup:
 push   

[Xen-devel] [PATCH v14 7/9] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - %esi register is used as a storage for Xen image load base address;
it is mostly unused in early boot code and preserved during C functions
calls in 32-bit mode,
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
---
v13 - suggestions/fixes:
- move gdt_boot_descr to .init.data section
  (suggested by Jan Beulich).

v12 - suggestions/fixes:
- store Xen image load base address directly into %esi,
- store Xen image load base address after x86_32_switch
  (suggested by Doug Goldstein),
- improve commit message.

v8 - suggestions/fixes:
   - use shld instead of mov and shr in BOOT_FS segment
 descriptor base address initialization
 (suggested by Jan Beulich),
   - simplify code updating frame addresses in page tables
 (suggested by Jan Beulich),
   - print Xen image base addresses using "%#lx" format
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - leave static mapping of first
 16 MiB in l2_identmap as is
 (suggested by Jan Beulich),
   - use xen_phys_start instead of xen_img_load_base_addr
 (suggested by Daniel Kiper and Jan Beulich),
   - simplify BOOT_FS segment descriptor
 base address initialization
 (suggested by Jan Beulich),
   - fix BOOT_FS segment limit
 (suggested by Jan Beulich),
   - do not rename sym_phys in this patch
 (suggested by Jan Beulich),
   - rename esi_offset/fs_offset to
 sym_esi/sym_fs respectively
 (suggested by Jan Beulich),
   - use add instead of lea in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |  170 -
 xen/arch/x86/boot/trampoline.S|5 ++
 xen/arch/x86/boot/x86_64.S|   21 +++--
 xen/arch/x86/setup.c  |   14 +--
 xen/arch/x86/x86_64/asm-offsets.c |3 +
 xen/include/asm-x86/page.h|2 +-
 6 files changed, 158 insertions(+), 57 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a085f16..156518c 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -13,12 +13,15 @@
 .code32
 
 #define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sy

[Xen-devel] [PATCH v14 9/9] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
  (suggested by Doug Goldstein).

v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loop
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   16 
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 30 insertions(+)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a1f69c0..7d71fbb 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offs(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -390,6 +397,15 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 87e573a..85639e4 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32   8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64   9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE   10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED  0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL  1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW  1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED   1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS  18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR  21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct 

[Xen-devel] [PATCH v14 5/9] x86: change default load address from 1 MiB to 2 MiB

[Daniel Kiper]

Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))

Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
---
v8 - suggestions/fixes:
   - drop first 2 MiB mapping from Xen image mapping
 (suggested by Jan Beulich),
   - improve commit message.

v7 - suggestions/fixes:
   - minor cleanups
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/Rules.mk  |3 +++
 xen/arch/x86/boot/head.S   |8 
 xen/arch/x86/boot/x86_64.S |5 +++--
 xen/arch/x86/setup.c   |3 ++-
 xen/arch/x86/xen.lds.S |2 +-
 6 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08e9f7b..e5b840e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 
$(XEN_IMG_OFFSET) \
   `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__2M_rwdata_end$$/0x\1/p'`
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 72be8b2..568657e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET := 0x20
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
 # Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 5147204..a085f16 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -511,14 +511,6 @@ trampoline_setup:
 mov %eax,sym_phys(boot_tsc_stamp)
 mov %edx,sym_phys(boot_tsc_stamp+4)
 
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
 /* Apply relocations to bootstrap trampoline. */
 mov sym_phys(trampoline_phys),%edx
 mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 4d507fb..f9d1022 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
  * page.
  */
 GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
 .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + 
(PAGE_HYPERVISOR | _PAGE_PSE)
 idx = idx + 1
 .endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d4b7d25..e6f6ef1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * Undo the temporary-hooking of the l1_identmap.  __2M_text_start
  * is contained in this PTE.
  */
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+   l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 76e18ab..6039496 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
   __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
 #endif
 
-  . = __XEN_VIRT_START + MB(1);
+  . = __XEN_VIRT_START + XEN_IMG_OFFSET;
   _start = .;
   .text : {
 _stext = .;/* Text and read-only data */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v14 0/9] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending fourteenth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes since v13:
  - changed patches: 2, 4.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 xen/arch/x86/Makefile |4 +-
 xen/arch/x86/Rules.mk |3 +
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  570 
++
 xen/arch/x86/boot/reloc.c |  154 +-
 xen/arch/x86/boot/trampoline.S|7 +-
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   46 +++
 xen/arch/x86/efi/Makefile |   14 +-
 xen/arch/x86/efi/efi-boot.h   |   60 +++--
 xen/arch/x86/efi/stub.c   |   39 ++
 xen/arch/x86/setup.c  |   24 ++--
 xen/arch/x86/x86_64/asm-offsets.c |   15 +++
 xen/arch/x86/xen.lds.S|   13 +-
 xen/common/efi/boot.c |   64 ++
 xen/common/efi/runtime.c  |9 ++
 xen/include/asm-x86/config.h  |5 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/config.h  |1 +
 xen/include/xen/multiboot2.h  |  182 ++
 20 files changed, 1095 insertions(+), 124 deletions(-)

Daniel Kiper (9):
  x86: add multiboot2 protocol support
  efi: build xen.gz with EFI code
  efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86: change default load address from 1 MiB to 2 MiB
  x86/setup: use XEN_IMG_OFFSET instead of...
  x86: make Xen early boot code relocatable
  x86/boot: rename sym_phys() to sym_offs()
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v14 4/9] x86: add multiboot2 protocol support for EFI platforms

[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 <daniel.ki...@oracle.com>
---
v14 - suggestions/fixes:
- mark .init.data section as writable; by the way we must change
  similar definition in xen/arch/x86/boot/x86_64.S because otherwise
  compiler complains about section types conflicts
  (suggested by Jan Beulich),
- use %r15 instead of %r15d
  (suggested by Jan Beulich),
- remove redundant add from UEFI stack alignment
  (suggested by Jan Beulich),
- use "mov (%rsp),%rdi" instead of "pop %rdi/push %rdi"
  (suggested by Jan Beulich),
- return void instead of paddr_t from efi_multiboot2()
  and then simplify a bit trampoline setup assembly
  (suggested by Jan Beulich),
- remove "(XEN)" from efi_multiboot2() stub error messages
  (suggested by Jan Beulich),
- move err from inline assembly OutputOperands to InputOperands in
  stub.c:efi_multiboot2(); this way we avoid following compile time error:
  stub.c: In function ‘efi_multiboot2’:
  stub.c:36:5: error: read-only variable ‘err’ used as ‘asm’ output
   asm volatile(
   ^~~
  issue was introduced by changing err type to "static const CHAR16 
__initconst";
  potentially we can revert this change but move to InputOperands looks 
better IMO;
  even if we are not able to specify %rdx in Clobbers; simply we do not care
  because next instruction after call is hlt
  (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga),
- take into account MBI_SPACE_MIN in ASSERT((trampoline_end - 
trampoline_start) < ...)
  (suggested by Jan Beulich),
- improve comments
  (suggested by Jan Beulich).

v13 - suggestions/fixes:
- move vga_text_buffer and efi_platform to .init.data section
  (suggested by Jan Beulich),
- reduce number of error branches in EFI code in xen/arch/x86/boot/head.S
  (suggested by Jan Beulich),
- rename run_bs label to .Lrun_bs
  (suggested by Jan Beulich),
- align the stack as UEFI spec requires
  (suggested by Jan Beulich),
- change trampoline region memory layout
  (suggested by Jan Beulich),
- revert changes in efi_arch_pre_exit_boot()
  (suggested by Jan Beulich),
- relocate_trampoline() must set trampoline_phys for all bootloaders;
  otherwise fallback allocator is always used if Xen was loaded with
  Multiboot2 protocol,
- change err type in efi_multiboot2() to "static const CHAR16 __initconst"
  (suggested by Jan Beulich),
- change asm "g" constraint to "rm" in efi_multiboot2()
  (suggested by Jan Beulich),
- improve comments
  (suggested by Jan Beulich and Doug Goldstein).

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

[Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
Acked-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Doug Goldstein <car...@cardoe.com>
---
v14 - suggestions/fixes:
- at least GNU Make 4.1 does not build efi/buildid.o if nothing
  depends on it; so, add "boot.init.o: buildid.o" dependency to
  force efi/buildid.o on some versions of make; I hope that this
  small change does not invalidate Acked-by/Reviewed-by; however,
  I am dropping Tested-by
  (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga).

v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   14 ++
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |9 +
 5 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..3edff1c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,16 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+boot.init.o: buildid.o
+
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff 

Re: [Xen-devel] [PATCH v14 2/9] efi: build xen.gz with EFI code

[Daniel Kiper]

On Thu, Feb 02, 2017 at 04:46:14PM -0600, Doug Goldstein wrote:
> On 2/2/17 4:41 PM, Daniel Kiper wrote:
> > On Thu, Feb 02, 2017 at 11:01:12PM +0100, Daniel Kiper wrote:
> >> Build xen.gz with EFI code. We need this to support multiboot2
> >> protocol on EFI platforms.
> >>
> >> If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
> >> it must contain "linear" (or "flat") representation of code and data.
> >> This is requirement of both boot protocols. Currently, PE file contains
> >> many sections which are not "linear" (one after another without any holes)
> >> or even do not have representation in a file (e.g. BSS). From EFI point
> >> of view everything is OK and works. However, this file layout cannot be
> >> properly interpreted by multiboot protocols family. In theory there is
> >> a chance that we could build proper PE file (from multiboot protocols POV)
> >> using current build system. However, it means that xen.efi further diverge
> >> from Xen ELF file (in terms of contents and build method). On the other
> >> hand ELF has all needed properties. So, it means that this is good starting
> >> point for further development. Additionally, I think that this is also good
> >> starting point for further xen.efi code and build optimizations. It looks
> >> that there is a chance that finally we can generate xen.efi directly from
> >> Xen ELF using just simple objcopy or other tool. This way we will have one
> >> Xen binary which can be loaded by three boot protocols: EFI native loader,
> >> multiboot (v1) and multiboot2.
> >>
> >> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
> >> Acked-by: Jan Beulich <jbeul...@suse.com>
> >> Reviewed-by: Doug Goldstein <car...@cardoe.com>
> >> ---
> >> v14 - suggestions/fixes:
> >> - at least GNU Make 4.1 does not build efi/buildid.o if nothing
> >>   depends on it; so, add "boot.init.o: buildid.o" dependency to
> >>   force efi/buildid.o on some versions of make; I hope that this
> >>   small change does not invalidate Acked-by/Reviewed-by; however,
> >>   I am dropping Tested-by
> >>   (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga).
> >
> > Diff as Doug asked:
> >
> > diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> > index 442f3fc..3edff1c 100644
> > --- a/xen/arch/x86/efi/Makefile
> > +++ b/xen/arch/x86/efi/Makefile
> > @@ -8,6 +8,8 @@ efi := $(if $(efi),$(shell rm disabled)y)
> >  %.o: %.ihex
> > $(OBJCOPY) -I ihex -O binary $< $@
> >
> > +boot.init.o: buildid.o
> > +
> >  obj-y := stub.o
> >  obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
> >  extra-$(efi) += buildid.o
> >
>
> FWIW, I had a similar fix for this cause I ran into it earlier today. I
> used runtime.o but I've switched to using boot.init.o so as to not
> conflict with you. This issue affects a lot more than this series so I'm

Great! Thanks a lot!

> going to mail mine once the tests finish at:
>
> https://travis-ci.org/cardoe/xen/builds/197819721

I am OK with it. If you wish you can add my
Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>
to this patch.

Daniel

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

Re: [Xen-devel] [PATCH v14 4/9] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Thu, Feb 02, 2017 at 11:01:14PM +0100, 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 <daniel.ki...@oracle.com>
> ---
> v14 - suggestions/fixes:
> - mark .init.data section as writable; by the way we must change
>   similar definition in xen/arch/x86/boot/x86_64.S because otherwise
>   compiler complains about section types conflicts
>   (suggested by Jan Beulich),
> - use %r15 instead of %r15d
>   (suggested by Jan Beulich),
> - remove redundant add from UEFI stack alignment
>   (suggested by Jan Beulich),
> - use "mov (%rsp),%rdi" instead of "pop %rdi/push %rdi"
>   (suggested by Jan Beulich),
> - return void instead of paddr_t from efi_multiboot2()
>   and then simplify a bit trampoline setup assembly
>   (suggested by Jan Beulich),
> - remove "(XEN)" from efi_multiboot2() stub error messages
>   (suggested by Jan Beulich),
> - move err from inline assembly OutputOperands to InputOperands in
>   stub.c:efi_multiboot2(); this way we avoid following compile time error:
>   stub.c: In function ‘efi_multiboot2’:
>   stub.c:36:5: error: read-only variable ‘err’ used as ‘asm’ output
>asm volatile(
>^~~
>   issue was introduced by changing err type to "static const CHAR16 
> __initconst";
>   potentially we can revert this change but move to InputOperands looks 
> better IMO;
>   even if we are not able to specify %rdx in Clobbers; simply we do not 
> care
>   because next instruction after call is hlt
>   (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga),
> - take into account MBI_SPACE_MIN in ASSERT((trampoline_end - 
> trampoline_start) < ...)
>   (suggested by Jan Beulich),
> - improve comments
>   (suggested by Jan Beulich).

Diff as Doug asked:

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 2ecdcb3..5147204 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -116,7 +116,7 @@ gdt_boot_descr:
 .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.data, "a", @progbits
+.section .init.data, "aw", @progbits
 .align 4
 
 vga_text_buffer:
@@ -173,9 +173,10 @@ not_multiboot:
 
 __efi64_mb2_start:
 /*
- * Multiboot2 spec says that here CPU is in 64-bit mode. However, there
- * is also guarantee that all code and data is always put by the 
bootloader
- * below 4 GiB. Hence, we can safely use in most cases 32-bit 
addressing.
+ * Multiboot2 spec says that here CPU is in 64-bit mode. However,
+ * there is also guarantee that all code and data is always put
+ * by the bootloader below 4 GiB. Hence, we can safely truncate
+ * addresses to 32-bits in most cases below.
  */
 
 cld
@@ -188,7 +189,7 @@ __efi64_mb2_start:
 je  .Lefi_multiboot2_proto
 
 /* Jump to not_multiboot after switching CPU to x86_32 mode. */
-lea not_multiboot(%rip),%r15d
+lea not_multiboot(%rip),%r15
 jmp x86_32_switch
 
 .Lefi_multiboot2_proto:
@@ -248,28 +249,34 @@ __efi64_mb2_start:
 cmpb$0,efi_platform(%rip)
 
 /* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
-lea .Lmb2_no_bs(%rip),%r15d
+lea .Lmb2_no_bs(%rip),%r15
 jz  x86_32_switch
 
 /* Is EFI SystemTable address provided by boot loader? */
 test%rsi,%rsi
 
 /* Jump to .Lmb2_no_st after switching CPU to x86_32 mode. */
-lea .Lmb2_no_st(%rip),%r15d
+lea .Lmb2_no_st(%rip),%r15
 jz  x86_32_switch
 
 /* Is EFI ImageHandle address provided by boot loader? */
 test%rdi,%rdi
 
 /* Jump to .Lmb2_no_ih after switching CPU to x86_32 mode. */
-lea .Lmb2_no_ih(%rip),%r15d
+lea .Lmb2_no_ih(%rip),%r15
 jz  x86_32_switch
 
-/* Align the stack as UEFI spec requires. */
-add $15,%rsp
+/*
+ * Align the stack as UEFI spec requires. Keep it aligned
+ * before efi_multiboot2() call by pushing/popping even
+ * numbers of items on it.
+ */
 and $~15,%rsp
 
+/* Save Multiboot2 magic on the stack. */
 push%rax
+
+/* Save EFI ImageHandle on the stack. */
 push%rdi
 
 /*
@@ -284,34 +291,26 @@ __efi64_mb2_start:
 xor %eax,%eax
 rep stosq
 
-pop %rdi
-
-/* Align the stack as UEFI spec r