[Xen-devel] [MULTIBOOT2 DOC PATCH v3 12/13] multiboot2: Add me to authors
.. and properly format author list.
Signed-off-by: Daniel Kiper
---
doc/multiboot.texi |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index f566114..08cc5c3 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -53,7 +53,9 @@ versions.
@titlepage
@sp 10
@title The Multiboot2 Specification version @value{VERSION}
-@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro
Ishiguro, Vladimir 'phcoder' Serbinenko
+@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn,
+@author Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko,
+@author Daniel Kiper
@page
@vskip 0pt plus 1filll
@insertcopying
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [MULTIBOOT2 DOC PATCH v3 13/13] multiboot2: Bump version to 2.0
.. and add 2016 to copyright.
Signed-off-by: Daniel Kiper
---
configure.ac |2 +-
doc/multiboot.texi |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b11961d..585b37a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@ dnl LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER
RESULTING FROM THE
dnl USE OF THIS SOFTWARE.
AC_PREREQ(2.59)
-AC_INIT([Multiboot], [1.6], [bug-g...@gnu.org])
+AC_INIT([Multiboot], [2.0], [bug-g...@gnu.org])
AC_CONFIG_SRCDIR([doc/multiboot.texi])
AC_CONFIG_HEADER([config.h])
AM_INIT_AUTOMAKE
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 08cc5c3..d20415d 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -20,7 +20,7 @@ Copyright @copyright{} 1995,96 Bryan Ford
Copyright @copyright{} 1995,96 Erich Stefan Boleyn
-Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010 Free Software
Foundation, Inc.
+Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010,2016 Free
Software Foundation, Inc.
@quotation
Permission is granted to make and distribute verbatim copies of
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation
On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote: > On December 6, 2016 5:52:48 PM EST, Daniel Kiper > wrote: > >Hi, > > > >This updated patch series adds description of the Multiboot2 protocol > >new > >features and fixes some issues found here and there. > > > >It applies to multiboot2 branch in GRUB2 git tree. > > Why not the master one? Because doc lives in multiboot2 branch. I am going to move it to master after 2.02 and then... > >Here is short list of changes since v2: > > - new patches: 01, 02, > > - changed patches: 07. > > > > How about the rename of the file? Or would it make sense > to do that in some other followup patches? ...rename relevant files. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 03/13] x86: allow EFI reboot method neither on EFI platforms...
On Wed, Dec 07, 2016 at 06:18:19AM -0700, Jan Beulich wrote: > >>> On 05.12.16 at 23:25, wrote: > > ..nor EFI platforms with runtime services enabled. > > Btw, was the title meant to read "... neither on non-EFI platforms ..."? Right, thanks for pointing this out. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C
On Wed, Dec 07, 2016 at 06:43:40AM -0700, Jan Beulich wrote: > >>> On 05.12.16 at 23:25, wrote: > > 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. > > > > Additionally, put all common cmdline.c and reloc.c definitions > > into defs.h header. This way we do not duplicate needlessly > > some stuff. > > > > And finally remove unused xen/include/asm-x86/config.h > > header from reloc.c dependencies. > > > > Suggested-by: Andrew Cooper > > Signed-off-by: Daniel Kiper > > Acked-by: Jan Beulich > > As you may have seen I've applied patches 2..4. I would also Great! Thanks a lot! > have applied this one, but it fails to apply cleanly. Whether > that's because it needs re-basing or because it can't be applied > out of order I can't tell. In order for you to not have to re-submit > the whole series all the time it would help if you moved > uncontroversial patches which make sense to be applied without > the rest of the series to the beginning of the series. Will do! Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 07/13] multiboot2: Add description of support for EFI boot services
On Wed, Dec 07, 2016 at 09:33:55AM -0500, Konrad Rzeszutek Wilk wrote: > ..snip.. > > --- a/doc/multiboot.texi > > +++ b/doc/multiboot.texi > > @@ -528,6 +528,66 @@ The physical address to which the boot loader should > > jump in order to > > start running the operating system. > > @end table > > > > +@subsection EFI i386 entry address tag of Multiboot2 header > > + > > +@example > > +@group > > ++---+ > > +u16 | type = 8 | > > +u16 | flags | > > > Would it make sense to describe what 'flags' should contain? Or at least > if there is nothing yet there mention that the value is ignored and > should be zero? 'flags' is generic field and it is described earlier in the document. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation
On Wed, Dec 07, 2016 at 09:34:30AM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 07, 2016 at 12:26:19PM +0100, Daniel Kiper wrote: > > On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote: > > > On December 6, 2016 5:52:48 PM EST, Daniel Kiper > > > wrote: > > > >Hi, > > > > > > > >This updated patch series adds description of the Multiboot2 protocol > > > >new > > > >features and fixes some issues found here and there. > > > > > > > >It applies to multiboot2 branch in GRUB2 git tree. > > > > > > Why not the master one? > > > > Because doc lives in multiboot2 branch. I am going to > > move it to master after 2.02 and then... > > > > > >Here is short list of changes since v2: > > > > - new patches: 01, 02, > > > > - changed patches: 07. > > > > > > > > > > How about the rename of the file? Or would it make sense > > > to do that in some other followup patches? > > > > ...rename relevant files. > > I only had one question on #7, otherwise feel free to stick > Reviewed-by: Konrad Rzeszutek Wilk Thanks a lot! > Thank you for documenting this! You are welcome! Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C
On Wed, Dec 07, 2016 at 06:27:58PM +0100, Daniel Kiper wrote: > On Wed, Dec 07, 2016 at 06:43:40AM -0700, Jan Beulich wrote: > > >>> On 05.12.16 at 23:25, wrote: > > > 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. > > > > > > Additionally, put all common cmdline.c and reloc.c definitions > > > into defs.h header. This way we do not duplicate needlessly > > > some stuff. > > > > > > And finally remove unused xen/include/asm-x86/config.h > > > header from reloc.c dependencies. > > > > > > Suggested-by: Andrew Cooper > > > Signed-off-by: Daniel Kiper > > > Acked-by: Jan Beulich > > > > As you may have seen I've applied patches 2..4. I would also > > Great! Thanks a lot! > > > have applied this one, but it fails to apply cleanly. Whether > > that's because it needs re-basing or because it can't be applied > > out of order I can't tell. In order for you to not have to re-submit I have checked it. It requires at least some changes made by patch #1 which has "Reviewed-by: Jan Beulich ". Of course I can change this but then I think that I should drop your Reviewed-by from #1 and your Acked-by from #8. Does it pays? I think that we can do that in a bit different way. If there are no more comments please apply everything as is. If any new comment, worth taking into account, pop up I can rearrange patches order and drop your Reviewed-by/Acked-by too. Does it work for you? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation
On Tue, Dec 06, 2016 at 11:52:48PM +0100, Daniel Kiper wrote: > Hi, > > This updated patch series adds description of the Multiboot2 protocol new > features and fixes some issues found here and there. > > It applies to multiboot2 branch in GRUB2 git tree. > > Here is short list of changes since v2: > - new patches: 01, 02, > - changed patches: 07. If there are no more objections then I will apply this patch series at the beginning of next week. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C
On Fri, Dec 09, 2016 at 01:19:24AM -0700, Jan Beulich wrote: > >>> On 09.12.16 at 00:08, wrote: [...] > > I have checked it. It requires at least some changes made by patch #1 which > > has "Reviewed-by: Jan Beulich ". Of course I can change > > this but then I think that I should drop your Reviewed-by from #1 and your > > Acked-by from #8. > > Unless you change the structure of the code you move, I don't think > either of the tags would require dropping. I think that code move will be sufficient and logic should not change. So, if it works in that way I will leave your tags as is. > > Does it pays? I think that we can do that in a bit different > > way. If there are no more comments please apply everything as is. > > I think Andrew and I are in agreement that we're not at the point > yet where everything can go in as is. Please be patient - this has > taken so long to get where it is now that I don't think there's a > reason to rush anything now. And you may have noticed that > there have been quite a few other patch submissions which also > all want dealing with. Andrew and I should also be allowed some > room to actually do some work of our own ... I understand that. This is not a problem for me. However, I would like to see my patches in 4.9. Otherwise I am spinning around and cannot efficiently continue my work which partially depends on this patch series. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.8 Development Update
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] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
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] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
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] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers
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
[Xen-devel] [PATCH v4 00/19] x86: multiboot2 protocol support
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
Its visibility is not needed and just pollute symbol table. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- 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
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 Signed-off-by: Daniel Kiper --- 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 */ -/* 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 06/19] x86/boot/reloc: create generic alloc and copy functions
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
---
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...
..nor EFI platforms with runtime services disabled.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
---
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()
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
Signed-off-by: Daniel Kiper
---
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 = &bootsym(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_BOOT) )
retur
[Xen-devel] [PATCH v4 03/19] x86/boot: create *.lnk files with linker script
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
---
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 $< -
[Xen-devel] [PATCH v4 07/19] x86/boot: use %ecx instead of %eax
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 Reviewed-by: Andrew Cooper Reviewed-by: Konrad Rzeszutek Wilk --- 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 04/19] x86/boot/reloc: reduce assembly usage as much as possible
Next patch will leave just required jmp instruction
in xen/x86/boot/reloc.c.
Signed-off-by: Daniel Kiper
---
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"
- : "=&r" (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
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
---
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
[Xen-devel] [PATCH v4 08/19] x86/boot/reloc: Rename some variables and rearrange code a bit
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
---
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 09/19] x86: add multiboot2 protocol support
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 --- 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.00/grub-core/tests/boot/kernel
[Xen-devel] [PATCH v4 13/19] efi: EFI_RS bit in efi.flags must be controlled by efi=[no-]rs command line argument
Otherwise efi_enabled(EFI_RS) check is unreliable.
Signed-off-by: Daniel Kiper
---
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, &efi.flags);
+}
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
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- 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 %edi,%edi
[Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code
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
---
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
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
Signed-off-by: Daniel Kiper
---
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.*) \
+ .data|.data.*|.bss.*) \
[Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
---
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, &efi.flags);
+#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
+__set_bit(EFI_RS, &efi.flags);
+#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
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 --- 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 $(TARGET) 0x10 \ - `$(NM) -nr $(TA
[Xen-devel] [PATCH v4 15/19] x86/efi: create new early memory allocator
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
---
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;
+start =
[Xen-devel] [PATCH v4 19/19] x86: add multiboot2 protocol support for relocatable images
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 --- 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 MULTIBOOT2_TAG_ALIGN
Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions
On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote: > >>> On 11.08.16 at 16:12, wrote: > On 06.08.16 at 01:04, wrote: > >> --- 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) > > > > Conversion of alloc to be of pointer type (in the earlier patch), and > > then making the return type here and ... > > > >> +static u32 copy_mem(u32 src, u32 bytes) > > > > ... all of the types here follow suit would apparently be quite > > beneficial to the number of casts needed. > > Or maybe, considering patch 8, in a slight variation thereof: Do > the conversion as suggested, but have a helper wrapper of the > type above, taking care of all the casting. That way both the > actual implementation and the callers can stay (mostly) cast free. We should take into account patch 9 here too. Looking at code after it I think that right now it is very well optimized in terms of casts. I cannot see room for further improvement. Every change you proposed here and there does not improve final code. It justs move/change casts to/in different places. So, I think that it does not pay change casts here and in earlier patches. At least in the way you proposed until now. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support
On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04, wrote:
[...]
> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> > +mbi_out->flags |= MBI_MEMMAP;
> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
>
> Okay, here you use the entry size as provided by grub, allowing
> compatibility even when the boot loader uses a newer layout (with
> extra fields added to the end). However ...
>
> > +mbi_out->mmap_length *= sizeof(memory_map_t);
> > +
> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> > +
> > +mmap_src = get_mb2_data(tag, mmap, entries);
> > +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> > +
> > +for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t);
> > i++ )
> > +{
> > +/* Init size member properly. */
> > +mmap_dst[i].size = sizeof(memory_map_t);
> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> > +/* Now copy a given region data. */
> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
>
> ... here you index an array of type multiboot2_memory_map_t.
All calculations looks correct, so, I am not sure what is wrong here.
> Also note that in any event you should check that
> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
> to go with the flexible model, ==).
This make sense to some extent. However, I am not sure what we should do
if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
model). Just do not fill memory map? Probably yes...
> > +typedef struct {
> > +u32 type;
> > +u32 size;
> > +char string[0];
>
> This is not a public header - please omit the 0 here and in a similar
> place further down, as we're using all sorts of gcc extensions anyway.
OK.
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c
On Wed, Aug 17, 2016 at 09:56:39AM -0600, Jan Beulich wrote: > >>> On 06.08.16 at 01:04, wrote: > > 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 > > --- > > 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), > > I recall I didn't like where you placed it last time round. I've just tried > to locate the old thread, but going back a whole year in the list archives > I was not able to find a mail with the title containing "move efi". Hence I Here it is (I list just first email from thread in a given month): https://lists.xen.org/archives/html/xen-devel/2016-04/msg02186.html https://lists.xen.org/archives/html/xen-devel/2016-05/msg02659.html https://lists.xen.org/archives/html/xen-devel/2016-06/msg00124.html https://lists.xen.org/archives/html/xen-devel/2016-07/msg00530.html > can only say what I think now, without reference to earlier remarks: > The struct currently isn't overly large, but I still don't see why non-EFI > builds need to include it instead of just the flags variable you mean to > introduce subsequently. And it's even less obvious what use it is on > platforms not even supporting EFI, i.e. ARM32. I see two solutions for this issue: - define efi struct members conditionally; this requires also some #ifs sprinkled over Xen code (not very nice) or other substantial changes, - replace efi.flags with efi_flags and leave existing code as is. What is your choice? Personally I prefer existing patch (maybe with minimal changes suggested by you). Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage
On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
> >>> On 06.08.16 at 01:04, wrote:
>
> Apart from the question of this probably better getting merged with
> the previous patch ...
>
> > --- 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, &efi.flags);
> >
> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
> > +__set_bit(EFI_RS, &efi.flags);
> > +#endif
>
> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
> was given (and then efi_rs_enable) should go away. Oh, looks
> like that's the next patch, but I'd then again question the split.
Do you suggest that patches 11-13 should be merged into one thing?
If it is OK for you I can do that.
> > --- 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? */
>
> Why is this not the sequentially next number?
I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support
On Thu, Aug 18, 2016 at 03:43:54AM -0600, Jan Beulich wrote:
> >>> On 18.08.16 at 11:23, wrote:
> > On Wed, Aug 17, 2016 at 09:39:58AM -0600, Jan Beulich wrote:
> >> >>> On 06.08.16 at 01:04, wrote:
> >
> > [...]
> >
> >> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> >> > +mbi_out->flags |= MBI_MEMMAP;
> >> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> >> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> >> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
> >>
> >> Okay, here you use the entry size as provided by grub, allowing
> >> compatibility even when the boot loader uses a newer layout (with
> >> extra fields added to the end). However ...
> >>
> >> > +mbi_out->mmap_length *= sizeof(memory_map_t);
> >> > +
> >> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> >> > +
> >> > +mmap_src = get_mb2_data(tag, mmap, entries);
> >> > +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> >> > +
> >> > +for ( i = 0; i < mbi_out->mmap_length /
> >> > sizeof(memory_map_t); i++
> > )
> >> > +{
> >> > +/* Init size member properly. */
> >> > +mmap_dst[i].size = sizeof(memory_map_t);
> >> > +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> >> > +/* Now copy a given region data. */
> >> > +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> >> > +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >>
> >> > 32);
> >> > +mmap_dst[i].length_low = (u32)mmap_src[i].len;
> >> > +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);
> >>
> >> ... here you index an array of type multiboot2_memory_map_t.
> >
> > All calculations looks correct, so, I am not sure what is wrong here.
> >
> >> Also note that in any event you should check that
> >> entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
> >> to go with the flexible model, ==).
> >
> > This make sense to some extent. However, I am not sure what we should do
> > if entry_size < sizeof(*mmap_src) (I think that we should assume flexible
> > model). Just do not fill memory map? Probably yes...
>
> Perhaps you misunderstood my comment?
> entry_size < sizeof(*mmap_src) is a case we simply can't deal with,
> so you should (as you say) not obtain the memory map, which I
> assume is equivalent to not failing the boot altogether. The point
Yep.
> of interest really is entry_size > sizeof(*mmap_src), and that's
> what mmap_src[i] above doesn't handle correctly.
Ahhh... I have missed that. So, we can fix it in that way:
mmap_src = (void *)mmap_src + i * get_mb2_data(tag, mmap, entry_size);
mmap_dst[i].base_addr_low = (u32)mmap_src.addr;
...
Does it make sense?
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage
On Thu, Aug 18, 2016 at 05:18:01AM -0600, Jan Beulich wrote:
> >>> On 18.08.16 at 12:30, wrote:
> > On Wed, Aug 17, 2016 at 10:12:32AM -0600, Jan Beulich wrote:
> >> >>> On 06.08.16 at 01:04, wrote:
> >>
> >> Apart from the question of this probably better getting merged with
> >> the previous patch ...
> >>
> >> > --- 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, &efi.flags);
> >> >
> >> > +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
> >> > +__set_bit(EFI_RS, &efi.flags);
> >> > +#endif
> >>
> >> ... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
> >> was given (and then efi_rs_enable) should go away. Oh, looks
> >> like that's the next patch, but I'd then again question the split.
> >
> > Do you suggest that patches 11-13 should be merged into one thing?
> > If it is OK for you I can do that.
> >
> >> > --- 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_BOOT0 /* Were we booted from EFI? */
> >> > +#define EFI_RS 2 /* Can we use runtime services? */
> >>
> >> Why is this not the sequentially next number?
> >
> > I wish that EFI_LOADER (added in patch 16) has number 1 (next to EFI_BOOT).
>
> That'll then too end up more natural by merging the patches.
Potentially we can do that but patch 14 and 15 use efi_enabled().
So, we should merge patches 11-13 if you wish and leave 14-16 as is.
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 06/19] x86/boot/reloc: create generic alloc and copy functions
On Thu, Aug 18, 2016 at 03:41:06AM -0600, Jan Beulich wrote: > >>> On 18.08.16 at 10:53, wrote: > > On Thu, Aug 11, 2016 at 08:17:58AM -0600, Jan Beulich wrote: > >> >>> On 11.08.16 at 16:12, wrote: > >> On 06.08.16 at 01:04, wrote: > >> >> --- 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) > >> > > >> > Conversion of alloc to be of pointer type (in the earlier patch), and > >> > then making the return type here and ... > >> > > >> >> +static u32 copy_mem(u32 src, u32 bytes) > >> > > >> > ... all of the types here follow suit would apparently be quite > >> > beneficial to the number of casts needed. > >> > >> Or maybe, considering patch 8, in a slight variation thereof: Do > >> the conversion as suggested, but have a helper wrapper of the > >> type above, taking care of all the casting. That way both the > >> actual implementation and the callers can stay (mostly) cast free. > > > > We should take into account patch 9 here too. Looking at code after > > it I think that right now it is very well optimized in terms of casts. > > I cannot see room for further improvement. Every change you proposed > > here and there does not improve final code. It justs move/change casts > > to/in different places. So, I think that it does not pay change casts > > here and in earlier patches. At least in the way you proposed until now. > > What I've suggested above at least makes both the actual function > and its wrapper consistent, and hence usable (without casts) by > callers dealing with either only numbers of only pointers. Are you > saying there are no such "clean" callers? That would put the overall > code in a pretty bad light imo. alloc_mem() is mostly used by callers playing with numbers only. copy_mem() is only one user of it which plays with pointers. However, copy_mem() returns numbers, so, wrapper does not change a lot. It just moves casts to other places. Am I missing something? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/19] efi: build xen.gz with EFI code
On Fri, Aug 19, 2016 at 03:24:15AM -0600, Jan Beulich wrote: > >>> On 06.08.16 at 01:04, wrote: > > --- 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 ) > > Remind me please - in your new model, what memory map does > Xen consume? The raw EFI one, or the one presented by grub? The former one. GRUB does not provide memory maps on EFI platforms if image (in our case Xen) requested access to boot services. They would be bogus. > In the latter case the above would need to use EFI_LOADER > afaict; in the former case feel free to add my ack here. OK, thanks! Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 03/16] x86/boot: create *.lnk files with linker script
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 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
---
v5 - suggestions/fixes:
- merge __ALL__ text and data sections into one .text section
(suggested by Jan Beulich),
- check that .got.plt size is correct
(suggested by Jan Beulich),
- reformat comments
(suggested by Jan Beulich),
- improve commit message.
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 | 52 +
xen/arch/x86/boot/build32.mk | 16 +++--
2 files changed, 61 insertions(+), 7 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..da35aee
--- /dev/null
+++ b/xen/arch/x86/boot/build32.lds
@@ -0,0 +1,52 @@
+/*
+ * 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.*)
+*(.data)
+*(.data.*)
+*(.rodata)
+*(.rodata.*)
+*(.bss)
+*(.bss.*)
+ }
+
+ /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..39e6453 100644
--- a/xen/arch/x86/boot/build32.mk
+++ b/xen/arch/x86/boot/build32.mk
@@ -12,20 +12,22 @@ 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 $< $@
-
-%.lnk: %.o
- $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
+ $(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.*) \
- test $$sz != 0 || continue; \
+ .got.plt) \
+ t
[Xen-devel] [PATCH v5 01/16] x86: allow EFI reboot method neither on EFI platforms...
..nor EFI platforms with runtime services enabled.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
---
v5 - suggestions/fixes:
- fix build error
(suggested by Jan Beulich),
- improve commit message.
---
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..972e20b 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 )
+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 v5 00/16] x86: multiboot2 protocol support
Hi, I am sending fifth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues (many of them were found by Jan Beulich; thanks a lot!). 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 v4: - changed patches: 01, 03, 04, 05, 09, 10, 11. Patches 12-16 were reviewed by nobody last time. 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 next week. 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 | 52 xen/arch/x86/boot/build32.mk | 18 ++- 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 | 249 xen/arch/x86/boot/trampoline.S| 22 +++- xen/arch/x86/boot/video.S |7 - 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 | 33 - 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| 16 ++- xen/common/efi/boot.c | 31 - xen/common/efi/runtime.c | 21 ++- 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 | 10 +- xen/include/xen/multiboot2.h | 182 ++ 33 files changed, 1624 insertions(+), 614 deletions(-) Daniel Kiper (16): 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: 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 https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 05/16] x86/boot: call reloc() using stdcall calling convention
Current reloc() call method makes confusion and does not scale well for more arguments. And subsequent patch adding multiboot2 protocol support have to pass 3 arguments instead of 2. Hence, move reloc() call to stdcall calling convention. One may argue that we should use standard cdecl calling convention. However, stdcall is better here than cdecl because we do not need to remove "manually" arguments from stack in xen/arch/x86/boot/head.S assembly file. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- v5 - suggestions/fixes: - improve commit message (suggested by Jan Beulich). 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 */ -/* 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 v5 04/16] x86/boot/reloc: reduce assembly usage as much as possible
..to increase code readability and ease its maintenance.
Signed-off-by: Daniel Kiper
---
v5 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/reloc.c | 52 ++---
1 file changed, 25 insertions(+), 27 deletions(-)
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"
- : "=&r" (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 v5 02/16] x86/boot: remove multiboot1_header_end from symbol table
Its visibility is not needed and just pollute symbol table. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper --- 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 v5 06/16] x86/boot/reloc: create generic alloc and copy functions
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
---
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 v5 07/16] x86/boot: use %ecx instead of %eax
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 Reviewed-by: Andrew Cooper Reviewed-by: Konrad Rzeszutek Wilk --- 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 v5 11/16] efi: build xen.gz with EFI code
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
Acked-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 | 11 +++
xen/arch/x86/xen.lds.S|4 ++--
xen/common/efi/boot.c |3 +++
xen/common/efi/runtime.c |6 ++
5 files changed, 15 insertions(+), 11 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/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 2d1d43d..40eb4c5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -262,10 +262,10 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
+ efi = DEFINED(efi) ? efi : .;
+
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index d7c484e..48ef8ad 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1249,6 +1249,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 6bffda0..64c632c 100644
--- a/xen/common/efi/runtime.c
+++ b/xen/common/efi/runtime.c
@@ -175,6 +175,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *inf
[Xen-devel] [PATCH v5 08/16] x86/boot/reloc: rename some variables and rearrange code a bit
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
Acked-by: Jan Beulich
---
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 v5 09/16] x86: add multiboot2 protocol support
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 --- 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 | 144 +-- xen/arch/x86/x86_64/asm-offsets.c |9 ++ xen/include/xen/multiboot2.h | 169 + 5 files changed, 422 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\@
[Xen-devel] [PATCH v5 10/16] efi: create efi_enabled()
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 defines
EFI_BOOT, EFI_LOADER and EFI_RS features. EFI_BOOT is equal
to old efi_enabled == 1. EFI_RS ease control on runtime
services usage. EFI_LOADER tells that Xen was loaded
directly from EFI as PE executable.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
---
v5 - suggestions/fixes:
- squash three patches into one
(suggested by Jan Beulich),
- introduce all features at once
(suggested by Jan Beulich),
- efi_enabled() returns bool_t
instead of unsigned int
(suggested by Jan Beulich),
- update commit message.
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|7 ---
xen/arch/x86/mpparse.c |4 ++--
xen/arch/x86/setup.c | 14 --
xen/arch/x86/shutdown.c|4 ++--
xen/arch/x86/time.c|2 +-
xen/common/efi/boot.c | 17 +
xen/common/efi/runtime.c | 15 +--
xen/drivers/acpi/osl.c |2 +-
xen/include/xen/efi.h |9 +++--
11 files changed, 50 insertions(+), 30 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..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_rs_using_pgtables() )
+if ( efi_enabled(EFI_RS) && efi_rs_using_pgtables() )
return NULL;
/*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..f087023 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,9 +4,10 @@
#include
#include
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
+bool_t efi_enabled(int feature)
+{
+return false;
+}
void __init efi_init_memory(void) { }
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 8ae897a..360ca59 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -439,8 +439,8
[Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator
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
---
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 |2 ++
xen/arch/x86/setup.c|5 ++--
xen/include/xen/efi.h |1 +
4 files changed, 56 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;
+start =
[Xen-devel] [PATCH v5 14/16] x86/boot: implement early command line parser in C
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 Signed-off-by: Daniel Kiper --- 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.mk |2 + 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 |7 - 10 files changed, 408 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 d193820..23637d8 100644 --- a/.gitignore +++ b/.gitignore @@ -248,9 +248,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.mk b/xen/arch/x86/boot/build32.mk index 39e6453..3d01698 100644 --- a/xen/arch/x86/boot/build32.mk +++ b/xen/arch/x86/boot/build32.mk @@ -32,6 +32,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 - -#include "video.h" - -# NB. String pointer on stack is modified to point past parsed digits. -.Latoi: -push%ebx -push%ecx -p
[Xen-devel] [PATCH v5 13/16] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- 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/x86_64/asm-offsets.c |2 + xen/arch/x86/xen.lds.S|4 +- xen/common/efi/boot.c | 11 ++ 6 files changed, 312 insertions(+), 21 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 %edi,%edi # No VGA text buffer +jmp 1f +0: mov sym_phys(vga_text_buffer),%edi 1:
[Xen-devel] [PATCH v5 16/16] x86: add multiboot2 protocol support for relocatable images
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 --- 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 8dd5800..feb4297 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 MULTIBOOT2_TAG_ALIGN
[Xen-devel] [PATCH v5 15/16] x86: make Xen early boot code relocatable
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 --- 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 $(TARGET) 0x10 \ - `$(NM) -nr $(TA
Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms
On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>> On 13.01.17 at 20:21, wrote: > > Doug v1 - fix incorrect assembly (identified by Andrew Cooper) > > - fix issue where the trampoline size was left as 0 and the > > way the memory is allocated for the trampolines we would go to > > the end of an available section and then subtract off the size > > to decide where to place it. The end result was that we would > > always copy the trampolines and the 32-bit stack into some > > form of reserved memory after the conventional region we > > wanted to put things into. On some systems this did not > > manifest as a crash while on others it did. Reworked the > > changes to always reserve 64kb for both the stack and the size > > of the trampolines. Added an ASSERT to make sure we never blow > > through this size. > > Without having looked at the patch in detail, but knowing I did closely > look at earlier versions (and iirc I was mostly fine with v10) the way > the above is written would require me to either inter-diff the patches, > or re-review the whole thing. For a large patch like this it would be > rather helpful to be quite a bit more specific as to where exactly in the > patch changes were made. I would prefer to not have this patch series applied because it will make me more difficult to prepare v12. I hope that I will post it in about 2 weeks. Though I am going to take into account all comments posted by Doug for v11. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms
On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > On 1/16/17 7:50 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>>>> On 13.01.17 at 20:21, wrote: > >>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) > >>> - fix issue where the trampoline size was left as 0 and the > >>> way the memory is allocated for the trampolines we would go to > >>> the end of an available section and then subtract off the size > >>> to decide where to place it. The end result was that we would > >>> always copy the trampolines and the 32-bit stack into some > >>> form of reserved memory after the conventional region we > >>> wanted to put things into. On some systems this did not > >>> manifest as a crash while on others it did. Reworked the > >>> changes to always reserve 64kb for both the stack and the size > >>> of the trampolines. Added an ASSERT to make sure we never blow > >>> through this size. > >> > >> Without having looked at the patch in detail, but knowing I did closely > >> look at earlier versions (and iirc I was mostly fine with v10) the way > >> the above is written would require me to either inter-diff the patches, > >> or re-review the whole thing. For a large patch like this it would be > >> rather helpful to be quite a bit more specific as to where exactly in the > >> patch changes were made. > > > > I would prefer to not have this patch series applied because it will make me > > more difficult to prepare v12. I hope that I will post it in about 2 weeks. > > Though I am going to take into account all comments posted by Doug for v11. > > > > Daniel > > > > Why? They're the first 4 patches remaining of your series. It'll > literally be the following commands: > > git fetch origin > git rebase origin/staging If you changed something then probably this is not so simple. Second, Jan asked me to reorder some patches in the series. Last but not least, your patch series does not contain whole functionality which is needed to properly load Xen using multiboot2 protocol on most EFI platforms. So, as above. Though I appreciate your feedback and I will take all your changes into account. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms
On Mon, Jan 16, 2017 at 09:28:45AM -0500, Doug Goldstein wrote: > On 1/16/17 9:11 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > >> On 1/16/17 7:50 AM, Daniel Kiper wrote: > >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>>>>>> On 13.01.17 at 20:21, wrote: > >>>>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) > >>>>> - fix issue where the trampoline size was left as 0 and the > >>>>> way the memory is allocated for the trampolines we would go to > >>>>> the end of an available section and then subtract off the size > >>>>> to decide where to place it. The end result was that we would > >>>>> always copy the trampolines and the 32-bit stack into some > >>>>> form of reserved memory after the conventional region we > >>>>> wanted to put things into. On some systems this did not > >>>>> manifest as a crash while on others it did. Reworked the > >>>>> changes to always reserve 64kb for both the stack and the size > >>>>> of the trampolines. Added an ASSERT to make sure we never blow > >>>>> through this size. > >>>> > >>>> Without having looked at the patch in detail, but knowing I did closely > >>>> look at earlier versions (and iirc I was mostly fine with v10) the way > >>>> the above is written would require me to either inter-diff the patches, > >>>> or re-review the whole thing. For a large patch like this it would be > >>>> rather helpful to be quite a bit more specific as to where exactly in the > >>>> patch changes were made. > >>> > >>> I would prefer to not have this patch series applied because it will make > >>> me > >>> more difficult to prepare v12. I hope that I will post it in about 2 > >>> weeks. > >>> Though I am going to take into account all comments posted by Doug for > >>> v11. > >>> > >>> Daniel > >>> > >> > >> Why? They're the first 4 patches remaining of your series. It'll > >> literally be the following commands: > >> > >> git fetch origin > >> git rebase origin/staging > > > > If you changed something then probably this is not so simple. > > Second, Jan asked me to reorder some patches in the series. > > Last but not least, your patch series does not contain whole > > functionality which is needed to properly load Xen using > > multiboot2 protocol on most EFI platforms. So, as above. > > Though I appreciate your feedback and I will take all > > your changes into account. > > > > Daniel > > > > Yes there are some code changes which is the point of me sending this. > But the work for you is the same as having to rebase your series over > the past few years. Its still a rebase. Its the same thing that everyone > submitting patches has to do when they submit another version of their > patches. Yes, I know. It is always easy to say. And I do not know why you are in such a hurry. Could not you wait 1-2 weeks? > I believe you identified 1 machine that had an issue with the 1mb > region. I've used a 12 machines to test this series and these 4 patches > work on those machines. The relocation part of the series works on NONE > of the machines I've tested with. So I would argue the opposite. I still > haven't identified what's wrong with the relocation part of the series. This is very interesting. As I know similar thing is used on many machines for a year or two. And I have not received any complaints until now. Though I do not say that it is perfect. If you find something just drop me a line and I will fix it. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms
On Tue, Jan 17, 2017 at 12:05:21PM +, George Dunlap wrote: > On Mon, Jan 16, 2017 at 3:16 PM, Daniel Kiper wrote: [...] > >> Yes there are some code changes which is the point of me sending this. > >> But the work for you is the same as having to rebase your series over > >> the past few years. Its still a rebase. Its the same thing that everyone > >> submitting patches has to do when they submit another version of their > >> patches. > > > > Yes, I know. It is always easy to say. And I do not know why you are in > > such a hurry. Could not you wait 1-2 weeks? > > I can't speak to the technical merits of Doug's patch, but I have to > say I'm not very happy with this way of interacting. No one should be > able to block other people's valid contributions from going in to the > tree for their own convenience -- it discourages contribution and sets > the incentives all wrong. Doing a difficult rebase is something > everyone has to do sometimes; and it's not clear that it *will* be > difficult, as it sounds like Daniel hasn't even tried it. First of all, I would like to underline that never ever I would not like to hinder a cooperation here or anywhere else. If it looks like that then sorry. It was not my intention. Though at least until now I try to maintain this patch series and nothing will change (at least I do not have such plans) until it will be fully taken into Xen tree. I appreciate any feedback and in this case Doug's one. I am happy that more and more people testing it and find it useful. However, I think that it makes a confusion if we step on each other foot and everybody tries to post own version of a given patch series. I would not have any concerns if this project would be abandoned. However, this is not the case. Anyway, if maintainers and in particular Jan and/or Andrew will take decision to merge some or all Doug's patches I will not argue. And once again, I appreciate everybody feedback and in particular Doug's one. If I am missing something 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] kexec: implement STATUS hypercall to check if image is loaded
On Tue, Jan 17, 2017 at 11:29:16AM -0600, Eric DeVolder wrote: > The tools that use kexec are asynchronous in nature and do not keep > state changes. As such provide an hypercall to find out whether an > image has been loaded for either type. > > Note: No need to modify XSM as it has one size fits all check and > does not check for subcommands. > > Note: No need to check KEXEC_FLAG_IN_PROGRESS (and error out of > kexec_status()) as this flag is set only once by the first/only > cpu on the crash path. > > Note: This is just the Xen side of the hypercall, kexec-tools patch > to come separately. > > Signed-off-by: Konrad Rzeszutek Wilk > Signed-off-by: Eric DeVolder Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Followup corrections to kexec STATUS patch v3
On Wed, Jan 18, 2017 at 12:01:06PM -0600, Eric DeVolder wrote: > This contains the two corrections pointed out by Jan Beulich > for the kexec STATUS call just introduced. > > Note: In kexec_status(), the use of test_bit() can also return > EPERM, so the return value from test_bit() must be checked to > ensure that kexec_status() always returns 0, 1 or -1, per the > public header description. > > Note: My handling of the test_bit() scenario is to explicitly > check for return value of 1, so any value other than 1 causes > kexec_status to return 0. Great, however: - please use "git format-patch -n ..." to create patches, - first patch in the series should have [PATCH 0/3] in the subject, - both patches lack of your SOB. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms
On Wed, Jan 18, 2017 at 07:52:44AM -0700, Jan Beulich wrote: > >>> On 18.01.17 at 15:17, wrote: > > This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol > > support for EFI platforms'. > > > > - fix incorrect assembly (identified by Andrew Cooper) > > - fix issue where the trampoline size was left as 0 and the > > way the memory is allocated for the trampolines we would go to > > the end of an available section and then subtract off the size > > to decide where to place it. The end result was that we would > > always copy the trampolines and the 32-bit stack into some > > form of reserved memory after the conventional region we > > wanted to put things into. On some systems this did not > > manifest as a crash while on others it did. Reworked the > > changes to always reserve 64kb for both the stack and the size > > of the trampolines. Added a build time assert to make sure we have > > enough room always. > > > > Signed-off-by: Doug Goldstein > > Reviewed-by: Jan Beulich > with ... > > > --- a/xen/arch/x86/xen.lds.S > > +++ b/xen/arch/x86/xen.lds.S > > @@ -333,3 +333,10 @@ ASSERT(IS_ALIGNED(trampoline_start, 4), > > "trampoline_start misaligned") > > ASSERT(IS_ALIGNED(trampoline_end, 4), "trampoline_end misaligned") > > ASSERT(IS_ALIGNED(__bss_start, 8), "__bss_start misaligned") > > ASSERT(IS_ALIGNED(__bss_end,8), "__bss_end misaligned") > > + > > +/* The trampolines and the low memory stack must fit in 64kb. In testing > > + * the low memory stack never exceeded 1kb so just require that the > > + * trampolines fit in 63kb, leaving 1kb for the stack. > > + */ > > +ASSERT((trampoline_end - trampoline_start) < KB(63), > > +"not enough room for trampolines and low memory stack") > > ... the comment style here fixed (which could be done upon commit > or when Daniel merges this back into his series). Hmmm... Why this patch and #0 was not CC-ed to me? Anyway, it looks that I have cleared my backlog to some extent and now I am able to take a stab on v12. There is a chance that I will have it with Doug's and some additional fixes on Friday or Monday. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] Put back blank line for readability purposes.
On Wed, Jan 18, 2017 at 03:47:27PM -0600, Eric DeVolder wrote: > This blank line was accidentally removed during > the insertion of the kexec_status() declarations. > > Signed-off-by: Eric DeVolder Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] kexec: ensure kexec_status() always returns 0 or 1
On Wed, Jan 18, 2017 at 03:47:28PM -0600, Eric DeVolder wrote: > The use of test_bit() can also return EPERM, so the > return value from test_bit() must be checked to > ensure that kexec_status() always returns 0, 1 or > -1, per the public header description. > > Signed-off-by: Eric DeVolder Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] kexec: followup to STATUS patch v3 already in staging
On Wed, Jan 18, 2017 at 03:47:26PM -0600, Eric DeVolder wrote: > This contains the two corrections pointed out by Jan Beulich > for the kexec STATUS call just introduced. > > Note: In kexec_status(), the use of test_bit() can also return > EPERM, so the return value from test_bit() must be checked to > ensure that kexec_status() always returns 0, 1 or -1, per the > public header description. > > Note: My handling of the test_bit() scenario is to explicitly > check for return value of 1, so any value other than 1 causes > kexec_status to return 0. One nitpick. Subject should be: [PATCH v2 0/2] kexec: followup to STATUS patch v3 already in staging and then following patches should have in subject: [PATCH v2 1/2] ... [PATCH v2 2/2] ... However, IMO regardless of that patches can go in. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] kexec: ensure kexec_status() always returns 0 or 1
On Thu, Jan 19, 2017 at 01:07:52AM -0700, Jan Beulich wrote: > >>> On 18.01.17 at 22:47, wrote: > > The use of test_bit() can also return EPERM, so the > > return value from test_bit() must be checked to > > ensure that kexec_status() always returns 0, 1 or > > -1, per the public header description. > > Well, no, and this is rather disappointing. Did you look at the test_bit() > implementation, as I did suggest you do? As said before, it returns > non-zero if the bit was set, and zero if it was clear. It won't ever > return -EPERM (it was only your original code which converted the > meaning of ~0 to -EPERM). Hence the result here isn't much better > than the original. Errr... It looks that I have checked incorrect test_bit() implementation and my Reviewed-by was skewed. Sorry about that. Jan is right. You must use "!!" instead of "... == 1". And commit message is also incorrect... Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 4/5] x86: add multiboot2 protocol support for EFI platforms
On Thu, Jan 19, 2017 at 02:09:37AM -0700, Jan Beulich wrote: > >>> On 18.01.17 at 20:51, wrote: > > On 18/01/17 14:17, Doug Goldstein wrote: > >> +.Lefi_multiboot2_proto: > >> +/* Zero EFI SystemTable and EFI ImageHandle addresses. */ > >> +xor %esi,%esi > >> +xor %edi,%edi > >> + > >> +/* Skip Multiboot2 information fixed part. */ > >> +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx > >> +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx > > > > Are we strictly guaranteed to have the entire image, including multiboot > > tags, loaded below 4GB virtual even in the 64bit case? Even on non-EFI > > capable grub2's ? > > I can't speak for GrUB, but I've recently learned that EFI alone GRUB is able to enforce 4 GiB restriction. At least right now. However, I am afraid that sooner or later machines will appear in the wild which do not have memory below 4 GiB (well, they must have some below 1 MiB but everything above is not a must as I know) or everything will be reserved/used by EFI boot/runtime services, etc. Then GRUB will also fail and we will be forced to extend multiboot2 proto further. However, it looks that current solution should not change much then. > doesn't appear to make such guarantees, and also doesn't look > to have ways to request such address restricted loading of an Why? Due to lack of memory below 4 GiB, it being reserved for something, EFI implementation bugs or anything else? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms
On Wed, Jan 18, 2017 at 10:40:07PM -0500, Doug Goldstein wrote: > On 1/18/17 4:25 PM, Daniel Kiper wrote: > > On Wed, Jan 18, 2017 at 07:52:44AM -0700, Jan Beulich wrote: > >> ... the comment style here fixed (which could be done upon commit > >> or when Daniel merges this back into his series). > > > > Hmmm... Why this patch and #0 was not CC-ed to me? > > You say this like I did it intentionally to upset you. I switched to > using git-series and as a result my workflow changed slightly. When I > glanced at 1/5 it had you CCed and I assumed this one was as well. I do not know why you read this in that way. I have just stated the fact. No more no less. > > Anyway, it looks that I have cleared my backlog to some extent and now I am > > able to take a stab on v12. There is a chance that I will have it with > > Doug's > > and some additional fixes on Friday or Monday. > > So then there should be no issue with this landing before that or not. > The changes for you will be identical. A simple rebase --onto would > actually be easier than folding this into your larger series. I do not fully agree, however, I respect your point of view. Though I am not going to discuss this any longer. I have just stated my preference clearly earlier. Maintainers are the Supreme Court and they will decide what to do. And I am not going to discuss this too. I prefer to focus on my work. > Can you tell me what were the fixes to the relocation code? Unfortunately I have not received any details from you. Just vague statements that it does not work. So, I am not able to say anything about that. If you provide more details I am happy to help. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] kexec: ensure kexec_status() return bit value of 0 or 1
On Thu, Jan 19, 2017 at 11:10:53AM -0600, Eric DeVolder wrote: > When checking kexec_flags bit corresponding to the > requested image, ensure that 0 or 1 is returned. > > Signed-off-by: Eric DeVolder In general Reviewed-by: Daniel Kiper but... > --- > xen/common/kexec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/xen/common/kexec.c b/xen/common/kexec.c > index aa808cb..3da27bf 100644 > --- a/xen/common/kexec.c > +++ b/xen/common/kexec.c > @@ -1182,7 +1182,8 @@ static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) > uarg) > if ( kexec_load_get_bits(status.type, &base, &bit) ) > return -EINVAL; > > -return test_bit(bit, &kexec_flags); > +/* Ensure return bit value of 0 or 1 */ This is not needed here. "!!" is used very often and it is not an unusual stuff. So, it does not need any comment. However, I can agree that at first sight it looks strange. > +return !!test_bit(bit, &kexec_flags); Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
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
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
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 42be4bc..36e6386 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 b8f727a..22bd68d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -482,14 +482,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 139b2ca..7890374 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 3a02b2b..f9cdfc1 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 v12 05/10] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v12 - suggestions/fixes: - rename __efi64_start to __efi64_mb2_start (suggested by Andrew Cooper), - use efi_arch_memory_setup() machinery as trampoline et consortes main memory allocator (suggested by Doug Goldstein), - allocate space for mbi struct in efi_arch_memory_setup() too; this thing was not taken into account in earlier releases, - revert trampoline et consortes fallback memory allocator code in efi_arch_process_memory_map() to current upstream state (suggested by Doug Goldstein), - further simplify efi_arch_pre_exit_boot() code, - call efi_arch_memory_setup() from efi_multiboot2() (suggested by Doug Goldstein), - fix asembly call argument in xen/arch/x86/efi/stub.c (suggested by Andrew Cooper), - add ASSERT() for trampoline size (suggested by Doug Goldstein), - add KB() macro (suggested by Doug Goldstein), - improve comments (suggested by Andrew Cooper and Doug Goldstein). v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to increase code readability (suggested by Andrew Cooper). v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan Beulich). v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss) because latter is not tested extensively in different built environments yet (suggested by Andrew Cooper), - fix multiboot2 data scanning loop in x86_32 code (suggested by Jan Beulich), - add check for extra mem for mbi data if Xen is loaded via multiboot2 protocol on EFI platform (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v7 - suggestions/fixes: - do not allocate twice memory for trampoline if we were loaded via multiboot2 protocol on EFI platform, - wrap long line (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - improve label names in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - remove redundant BSS alignment, - update BSS alignment check, - use __set_bit() instead of set_bit() if possible (suggested by Jan Beulich), - call efi_arch_cpu() from efi_multiboot2() even if the same work is done later in other place right now (suggested by Jan Beulich), - xen/arch/x86/efi/stub.c:efi_multiboot2() fail properly on EFI platforms, - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - use 32-bit registers in x86_64 code if possible (suggested by Jan Beulich), - multiboot2 information address is 64-bit in x86_64 code, so, treat it is as is (suggested by Jan Beulich), - use cmovcc if possible, - leave only one space between rep and stosq (suggested by Jan Beulich), - improve error handling, - improve early error messages, (suggested by Jan Beulich), - improve early error messages printing code, - improve label names (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - various minor cleanups. v3 - suggestions/fixes: - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - improve segment registers initialization (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Beulich). v2 - suggestions/fixes: - generate multiboot2 header using macros (suggested by Jan Beulich), - switch CPU to x86_32 mode before jumping to 32-bit code (suggested by Andrew Cooper), - reduce code changes to increase patch readability (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform and find on my own multiboot2.mem_lower value, - stop execution if EFI platform is detected in legacy BIOS path. --- xen/arch/x86/boot/head.S | 268 ++--- xen/arch/x86/efi/efi-boot.h | 61 - xen/arch/x86/efi/stub.c | 38 ++ xen/arch/x86/x86_64/asm-offsets.c |2 + xen/arch/x86/xen.lds.S|7 +- xen/common/efi/boot.c | 11 ++ xen/include/asm-x86/config.h |5 + xen/include/xen/config.h |1 + 8 files changed, 366 insertions(+), 27 deletions
[Xen-devel] [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of...
..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- 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 v12 03/10] efi: build xen.gz with EFI code
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
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
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 | 12
xen/arch/x86/xen.lds.S|4 ++--
xen/common/efi/boot.c |3 +++
xen/common/efi/runtime.c |9 +
5 files changed, 19 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..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
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)
+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 --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,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/c
[Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support
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 Reviewed-by: Jan Beulich Reviewed-by: Doug Goldstein --- 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 | 144 +-- xen/arch/x86/x86_64/asm-offsets.c |9 ++ xen/include/xen/multiboot2.h | 169 + 5 files changed, 422 insertions(+), 10 deletions(-) create mode 100644 xen/include/xen/multiboot2.h diff --git a/xen/arch/x86/
[Xen-devel] [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images
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
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
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 bbc7cdd..fd0238b 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
@@ -383,6 +390,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 {
typedef struct {
u32 type;
u32 size;
+u32 load
[Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
Hi, I am sending twelfth 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 v11: - changed patches: 02, 05, 08, 10. Patch "x86/boot: implement early command line parser in C" was moved to the beginning of this patch series. It was requested by Jan. 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 |6 +- xen/arch/x86/Rules.mk |3 + xen/arch/x86/boot/Makefile| 12 +- xen/arch/x86/boot/build32.mk |2 + xen/arch/x86/boot/cmdline.S | 367 --- xen/arch/x86/boot/cmdline.c | 340 +++ xen/arch/x86/boot/defs.h | 58 + xen/arch/x86/boot/edd.S |3 - xen/arch/x86/boot/head.S | 543 ++ xen/arch/x86/boot/reloc.c | 151 +-- xen/arch/x86/boot/trampoline.S| 22 +++- xen/arch/x86/boot/video.S |7 -- xen/arch/x86/boot/wakeup.S|4 +- xen/arch/x86/boot/x86_64.S| 44 +++ xen/arch/x86/efi/Makefile | 12 +- xen/arch/x86/efi/efi-boot.h | 72 --- xen/arch/x86/efi/stub.c | 38 ++ 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 27 files changed, 1491 insertions(+), 513 deletions(-) Daniel Kiper (10): x86/boot: implement early command line parser in C 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 v12 09/10] x86/boot: rename sym_phys() to sym_offs()
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
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
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 f94a4ac..bbc7cdd 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)
@@ -110,7 +110,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 */
.align 4
@@ -130,23 +130,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:
@@ -351,7 +351,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
@@ -502,8 +502,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
@@ -576,22 +576,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. */
@@ -617,7 +617,7 @@ trampoline_setup:
push%eax
/* Copy bootstrap trampoline to low memory, below 1MB. */
-mov
[Xen-devel] [PATCH v12 08/10] x86: make Xen early boot code relocatable
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 --- 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 | 157 + 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, 152 insertions(+), 50 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 22bd68d..f94a4ac 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) sym_phys(sym)(%esi) +#define sym_fs(sym) %fs:sym_phys(sym) #define BOOT_CS320x0008 #define BOOT_CS640x0
[Xen-devel] [PATCH v12 01/10] x86/boot: implement early command line parser in C
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. Additionally, put all common cmdline.c and reloc.c definitions into defs.h header. This way we do not duplicate needlessly some stuff. And finally remove unused xen/include/asm-x86/config.h header from reloc.c dependencies. Suggested-by: Andrew Cooper Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- v7 - suggestions/fixes: - add min() macro (suggested by Jan Beulich), - add padding to early_boot_opts_t in more standard way (suggested by Jan Beulich), - simplify defs.h dependencies (suggested by Jan Beulich). v6 - suggestions/fixes: - put common cmdline.c and reloc.c definitions into defs.h header (suggested by Jan Beulich), - use xen/include/xen/stdbool.h and bool type from it instead of own defined bool_t (suggested by Jan Beulich), - define delim_chars as constant (suggested by Jan Beulich), - properly align trampoline.S:early_boot_opts struct (suggested by Jan Beulich), - fix overflow check in strtoui() (suggested by Jan Beulich), - remove unused xen/include/asm-x86/config.h header from reloc.c dependencies, - improve commit message. 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 | 11 +- xen/arch/x86/boot/build32.mk |2 + xen/arch/x86/boot/cmdline.S| 367 xen/arch/x86/boot/cmdline.c| 340 + xen/arch/x86/boot/defs.h | 58 +++ xen/arch/x86/boot/edd.S|3 - xen/arch/x86/boot/head.S |9 + xen/arch/x86/boot/reloc.c |9 +- xen/arch/x86/boot/trampoline.S | 15 ++ xen/arch/x86/boot/video.S |7 - 12 files changed, 438 insertions(+), 390 deletions(-) delete mode 100644 xen/arch/x86/boot/cmdline.S create mode 100644 xen/arch/x86/boot/cmdline.c create mode 100644 xen/arch/x86/boot/defs.h diff --git a/.gitignore b/.gitignore index 7689596..f41c3d0 100644 --- a/.gitignore +++ b/.gitignore @@ -252,9 +252,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 7f6b5d7..007dced 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -220,5 +220,5 @@ 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 rm -f note.o diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile index 5fdb5ae..6d20646 100644 --- a/xen/arch/x86/boot/Makefile +++ b/xen/arch/x86/boot/Makefile @@ -1,8 +1,15 @@ obj-bin-y += head.o -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h $(BASEDIR)/include/xen/multiboot.h +DEFS_H_DEPS = defs.h
[Xen-devel] [PATCH v12 04/10] efi: create new early memory allocator
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 Acked-by: Jan Beulich Acked-by: Julien Grall Reviewed-by: Doug Goldstein --- 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: - optimize ebmalloc allocator, - move ebmalloc machinery to xen/common/efi/boot.c (suggested by Jan Beulich), - enforce PAGE_SIZE ebmalloc_mem alig
Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms
On Thu, Jan 19, 2017 at 09:25:08AM -0500, Doug Goldstein wrote: > On 1/19/17 6:56 AM, Daniel Kiper wrote: > >> Can you tell me what were the fixes to the relocation code? > > > > Unfortunately I have not received any details from you. Just vague > > statements that it does not work. So, I am not able to say anything > > about that. If you provide more details I am happy to help. > > We discussed this on your original v11 thread. It fails on Intel NUCs, > Lenovo T430, Dell PowerEdge something (I'm on vacation so I can't see > the model number), HP Proliant ML10, QEMU (with OVMF) and some other Do you use QEMU with KVM enabled? I was hit twice by an issue (I do not remember the detail right now) when OVMF was running in KVM. When I disabled KVM then everything worked without any issue. It does not happen often but... > broads that I don't remember the model number off of my head. Its about > a dozen machines all together. They fail in two different ways: > > - the other CPUs are reported as stuck and the machine boots but 'xl > info' reports 1 available CPU. > - when the non-CPUs are brought up it dies when setting paging back into > cr0. > > Every single machine fails in one of these two ways. Hmmm... I have not seen that anywhere. And nobody except you reported such issue. Is it happening with GRUB2 and/or iPXE? Anyway, I have just released v12. It contains various fixes including yours. I hope that I have not missed anything. Please take a look. In the meantime I will try to find one of machines mentioned above and reproduce this issue there. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB
On Fri, Jan 20, 2017 at 01:49:46AM -0700, Jan Beulich wrote: > >>> On 20.01.17 at 05:06, wrote: > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > >> 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 > >> Reviewed-by: Jan Beulich > >> Reviewed-by: Doug Goldstein > > > > FWIW, I can't find where I offered my R-b for this patch. Its part of > > the series I've said fails on my hardware. > > Looks like you had responded to v11 00/13 without naming specific > patches the tag would apply to, so I think Daniel legitimately applied > it to the entire series. Whether he should have dropped it again > after your report of things not working is kind of fuzzy, unless at > some point you've explicitly withdrawn them (which I don't recall > you having done). Thanks Jan. Here is the exact email: https://lists.xen.org/archives/html/xen-devel/2016-12/msg02151.html Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 02:34, wrote:
> > @@ -100,20 +107,48 @@ multiboot2_header_start:
> > gdt_boot_descr:
> > .word 6*8-1
> > .long sym_phys(trampoline_gdt)
> > +.long 0 /* Needed for 64-bit lgdt */
> > +
> > +.align 4
> > +vga_text_buffer:
> > +.long 0xb8000
> > +
> > +efi_platform:
> > +.byte 0
>
> You mean to modify these fields, but you add them to a r/o section.
Yep. So, I think that we should move them to .init.data. Is it OK for you?
> > +.Lefi_multiboot2_proto:
> > +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> > +xor %esi,%esi
> > +xor %edi,%edi
> > +
> > +/* Skip Multiboot2 information fixed part. */
> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
>
> In an earlier reply to Andrew's inquiry regarding the possible
> truncation here you said that grub can be made obey to such a
> load restriction. None of the tags added here or in patch 2
> appear to have such an effect, so would you please clarify how
> the address restriction is being enforced?
GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
So, there is no need for extra tags.
Additionally, multiboot2 spec says this:
The bootloader must not load any part of the kernel, the modules, the Multiboot2
information structure, etc. higher than 4 GiB - 1. This requirement is put in
force because most of currently specified tags supports 32-bit addresses only.
Additionally, some kernels, even if they run on EFI 64-bit platform, still
execute some parts of its initialization code in 32-bit mode.
[...]
> > +.Lefi_mb2_next_tag:
> > +/* Go to next Multiboot2 information tag. */
> > +add MB2_tag_size(%rcx),%ecx
> > +add $(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +and $~(MULTIBOOT2_TAG_ALIGN-1),%ecx
> > +jmp .Lefi_mb2_tsize
> > +
> > +run_bs:
>
> .Lrun_bs:
OK.
> > +/* Are EFI boot services available? */
> > +cmpb$0,efi_platform(%rip)
> > +jnz 0f
> > +
> > +/* Jump to .Lmb2_no_bs after switching CPU to x86_32 mode. */
> > +lea .Lmb2_no_bs(%rip),%edi
> > +jmp x86_32_switch
> > +0:
>
> I realize you need to avoid clobbering %rdi in the non-error case,
> but the register choice seems sub-optimal: If you used a register
> which you can clobber here (e.g. %edx as it seems, using %edi in
> its place at x86_32_switch and cs32_switch), you could simplify
> this to
>
> cmpb ...
> lea ...
> je x86_32_switch
>
> at once avoiding all the numeric labels here.
If you do not care that it will be always loaded then OK. However, I think
that %r15d is a bit better here because if we need to add another argument
to efi_multiboot2() and we use %edx then we must change code in more places.
Of course we should do "mov %r15d,%edi" after x86_32_switch label then.
> > +2:
> > +push%rax
> > +push%rdi
> > +
> > +/*
> > + * Initialize BSS (no nasty surprises!).
> > + * It must be done earlier than in BIOS case
> > + * because efi_multiboot2() touches it.
> > + */
> > +lea __bss_start(%rip),%edi
> > +lea __bss_end(%rip),%ecx
> > +sub %edi,%ecx
> > +shr $3,%ecx
> > +xor %eax,%eax
> > +rep stosq
> > +
> > +pop %rdi
> > +
> > +/*
> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> > + * memory below this address is used for trampoline
> > + * stack, trampoline itself and as a storage for
> > + * mbi struct created in reloc().
> > + *
> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> > + * on EFI platforms. Hence, it could not be used like
> > + * on legacy BIOS platforms.
> > + */
> > +callefi_multiboot2
>
> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> further spec requirements for runtime calls") I'm worried about stack
> alignment here. Does GrUB call or jmp to our entry point (and is that
> firmly specified to be the case)? Perhaps it would be a good idea to
> align the stack earlier on in any case. Or if not (and if alignment at
> this call is ABI conforming), a comment should be left here to warn
> people of future modifications to the amount of items pushed onto /
> popped off the stack.
Multiboot2 spec requires that stack, among others, is passed to loaded
image according to UEFI spec. Though, IIRC, there are no extra stack checks
there. Maybe we should add something to GRUB2 if it does not exists.
> > +trampoline_setup:
> > +/* Save trampoline
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote:
> >>> On 20.01.17 at 12:43, wrote:
> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote:
> >> >>> On 20.01.17 at 02:34, wrote:
[...]
> >> > +.Lefi_multiboot2_proto:
> >> > +/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> >> > +xor %esi,%esi
> >> > +xor %edi,%edi
> >> > +
> >> > +/* Skip Multiboot2 information fixed part. */
> >> > +lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> >>
> >> In an earlier reply to Andrew's inquiry regarding the possible
> >> truncation here you said that grub can be made obey to such a
> >> load restriction. None of the tags added here or in patch 2
> >> appear to have such an effect, so would you please clarify how
> >> the address restriction is being enforced?
> >
> > GRUB2 itself does allocations for all multiboot2 stuff always below 4 GiB.
> > So, there is no need for extra tags.
> >
> > Additionally, multiboot2 spec says this:
> >
> > The bootloader must not load any part of the kernel, the modules, the
> > Multiboot2
> > information structure, etc. higher than 4 GiB - 1. This requirement is put
> > in
> > force because most of currently specified tags supports 32-bit addresses
> > only.
> > Additionally, some kernels, even if they run on EFI 64-bit platform, still
> > execute some parts of its initialization code in 32-bit mode.
>
> Okay, that's good enough for now, even if it escapes me how that's
> supposed to work on systems without any memory below 4Gb.
If you wish I can add relevant comment somewhere. Anyway, if there is no
mem below 4 GiB at least, IIRC, GRUB2 will fail during image load. So,
no worry. At least right now.
[...]
> >> > +/*
> >> > + * efi_multiboot2() is called according to System V AMD64 ABI:
> >> > + * - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> >> > + * - OUT: %rax - highest allocated memory address below 1 MiB;
> >> > + * memory below this address is used for
> >> > trampoline
> >> > + * stack, trampoline itself and as a storage for
> >> > + * mbi struct created in reloc().
> >> > + *
> >> > + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag is not provided
> >> > + * on EFI platforms. Hence, it could not be used like
> >> > + * on legacy BIOS platforms.
> >> > + */
> >> > +callefi_multiboot2
> >>
> >> Now that we had a need for commit f6b7fedc89 ("x86/EFI: meet
> >> further spec requirements for runtime calls") I'm worried about stack
> >> alignment here. Does GrUB call or jmp to our entry point (and is that
> >> firmly specified to be the case)? Perhaps it would be a good idea to
> >> align the stack earlier on in any case. Or if not (and if alignment at
> >> this call is ABI conforming), a comment should be left here to warn
> >> people of future modifications to the amount of items pushed onto /
> >> popped off the stack.
> >
> > Multiboot2 spec requires that stack, among others, is passed to loaded
> > image according to UEFI spec. Though, IIRC, there are no extra stack checks
> > there. Maybe we should add something to GRUB2 if it does not exists.
>
> That would imply they do a call (and not a jmp), which would make
> the present code correct afaict. As said, imo there should still be a
> warning added here, for anyone wanting to modify the stack layout.
Will do.
[...]
> >> > --- a/xen/include/asm-x86/config.h
> >> > +++ b/xen/include/asm-x86/config.h
> >> > @@ -73,6 +73,11 @@
> >> > #define STACK_ORDER 3
> >> > #define STACK_SIZE (PAGE_SIZE << STACK_ORDER)
> >> >
> >> > +#define MB_TRAMPOLINE_STACK_SIZEPAGE_SIZE
> >> > +#define MB_TRAMPOLINE_SIZE (KB(64) -
> >> > MB_TRAMPOLINE_STACK_SIZE)
> >>
> >> What's the reason for the MB_ prefixes here? The trampoline is
> >> always the same size, isn't it? Nor am I convinced we really need
> >
> > Please take a look at efi_arch_memory_setup(). Amount of memory allocated
> > for trampoline and other stuff depends on boot loader type. So, when I use
> > "MB_" I would like underline that this is relevant for multiboot protocols.
> > Though I think that we can use the same size for all protocols. However,
> > I would not like to touch native EFI loader case.
>
> You already don't touch it, and I see no reason why this should
> change. Yet this is orthogonal to the naming of the constants here.
OK.
> As said, the trampoline itself is always the same, and the stack
Yep.
> portion of it is simply unused in the native EFI loader case. Plus
Hmmm... That is interesting why? I must take a look at trampoline code.
> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the
> first place. Perhaps TRAMPOLINE_SPACE (and then covering both
> parts)?
So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is
OK for you? And I can agree that this is bet
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 07:10:32AM -0700, Jan Beulich wrote: > >>> On 20.01.17 at 14:46, wrote: > > On Fri, Jan 20, 2017 at 05:40:55AM -0700, Jan Beulich wrote: > >> >>> On 20.01.17 at 12:43, wrote: > >> > On Fri, Jan 20, 2017 at 02:46:47AM -0700, Jan Beulich wrote: > >> >> >>> On 20.01.17 at 02:34, wrote: > >> MB_TRAMPOLINE_SIZE is in no way the size of the trampoline in the > >> first place. Perhaps TRAMPOLINE_SPACE (and then covering both > >> parts)? > > > > So, I suppose that TRAMPOLINE_SPACE and TRAMPOLINE_STACK_SPACE is > > OK for you? And I can agree that this is better naming. > > Again, I don't see why you would need TRAMPOLINE_STACK_SPACE. If we use TRAMPOLINE_SPACE only for both trampoline and its stack then ASSERT() is not very reliable. There is chance that trampoline code will fill all space specified in TRAMPOLINE_SPACE and then there will be no space for stack at all. However, I can agree that chance is small if we assume 64 KiB space for trampoline and trampoline size is about 10 KiB right now. > >> >> two defines - except in the link time assertion you always use > >> >> the sum of the two. > >> >> > >> >> > +#define MBI_SIZE(2 * PAGE_SIZE) > >> >> > >> >> On top of Doug's question - if it is needed at all, what does this > >> > > >> > Please look around reloc() call in xen/arch/x86/boot/head.S. You quickly > >> > realize that there is following memory layout from top to bottom: > >> > > >> > +--+ > >> > | TRAMPOLINE_STACK | > >> > +--+ > >> > |TRAMPOLINE| > >> > +--+ > >> > |mbi struct| > >> > +--+ > >> > > >> >> match up with, i.e. how come this is 2 pages (and not 1 or 3)? > >> > > >> > Just thought that 8 KiB will be sufficient for Xen/modules arguments, > >> > memory map and other minor things. > >> > >> Even with a couple of dozen modules passed? But the primary > > > > Why not? The biggest thing is memory map. The rest are mostly > > command line strings and a few pointers. Modules itself live > > in different memory regions. > > Command line string may get lengthy. Do you think that we should have more than 8 KiB there? Anyway, I am more afraid about memory map size here. > >> question was left unanswered anyway: Does this need placing in > >> the low megabyte at all? And even if it does, especially if you > > > > I do not think so. I do not expect that anything in trampoline code > > touches it. So, we can put it anywhere below 4 GiB. However, then > > we need an allocator to properly allocate mbi struct region. And > > at this boot stage this is not an easy thing. > > Depending for how long you need that data to stay around, there IIRC, it is needed only during init phase. Probably later it can be dropped. > may be places to put it without much risk of overflowing anything. I am not sure about which places do you think. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Fri, Jan 20, 2017 at 11:22:21AM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending twelfth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed issues. > > What machines did you test this series on? It fails to boot with iPXE I have done tests on OVMF and IBM System x3550 M2. It works on both machines. I have tested multiboot/multiboot2 on legacy BIOS, multiboot2 on EFI and xen.efi on EFI. If it works on both OVMF and IBM System x3550 M2 I do not have any problems anywhere else. Or it happens very rarely. > and grub on an Intel NUC and another board I've got. I've also just Let's focus on GRUB2. It is well tested setup. If it works then we can move to iPXE. By the way, could you try xen.efi from current upstream and with my patches. It should work without any issue. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support
On Fri, Jan 20, 2017 at 04:52:30PM +, Andrew Cooper wrote:
> On 20/01/17 01:34, Daniel Kiper wrote:
> > @@ -101,3 +112,126 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32
> > trampoline)
> >
> > return mbi_out;
> > }
> > +
> > +static multiboot_info_t *mbi2_reloc(u32 mbi_in)
> > +{
> > +const multiboot2_fixed_t *mbi_fix = _p(mbi_in);
> > +const multiboot2_memory_map_t *mmap_src;
> > +const multiboot2_tag_t *tag;
> > +module_t *mbi_out_mods = NULL;
> > +memory_map_t *mmap_dst;
> > +multiboot_info_t *mbi_out;
> > +u32 ptr;
> > +unsigned int i, mod_idx = 0;
> > +
> > +ptr = alloc_mem(sizeof(*mbi_out));
> > +mbi_out = _p(ptr);
> > +zero_mem(ptr, sizeof(*mbi_out));
> > +
> > +/* Skip Multiboot2 information fixed part. */
> > +ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> > +
> > +/* Get the number of modules. */
> > +for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> > + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> > +{
> > +if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> > +++mbi_out->mods_count;
> > +else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> > +break;
> > +}
> > +
> > +if ( mbi_out->mods_count )
> > +{
> > +mbi_out->flags |= MBI_MODULES;
> > +mbi_out->mods_addr = alloc_mem(mbi_out->mods_count *
> > sizeof(*mbi_out_mods));
> > +mbi_out_mods = _p(mbi_out->mods_addr);
> > +}
> > +
> > +/* Skip Multiboot2 information fixed part. */
> > +ptr = ALIGN_UP(mbi_in + sizeof(*mbi_fix), MULTIBOOT2_TAG_ALIGN);
> > +
> > +/* Put all needed data into mbi_out. */
> > +for ( tag = _p(ptr); (u32)tag - mbi_in < mbi_fix->total_size;
> > + tag = _p(ALIGN_UP((u32)tag + tag->size, MULTIBOOT2_TAG_ALIGN)) )
> > +switch ( tag->type )
> > +{
> > +case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> > +mbi_out->flags |= MBI_LOADERNAME;
> > +ptr = get_mb2_string(tag, string, string);
> > +mbi_out->boot_loader_name = copy_string(ptr);
> > +break;
> > +
> > +case MULTIBOOT2_TAG_TYPE_CMDLINE:
> > +mbi_out->flags |= MBI_CMDLINE;
> > +ptr = get_mb2_string(tag, string, string);
> > +mbi_out->cmdline = copy_string(ptr);
> > +break;
> > +
> > +case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
> > +mbi_out->flags |= MBI_MEMLIMITS;
> > +mbi_out->mem_lower = get_mb2_data(tag, basic_meminfo,
> > mem_lower);
> > +mbi_out->mem_upper = get_mb2_data(tag, basic_meminfo,
> > mem_upper);
> > +break;
> > +
> > +case MULTIBOOT2_TAG_TYPE_MMAP:
> > +if ( get_mb2_data(tag, mmap, entry_size) < sizeof(*mmap_src) )
> > +break;
> > +
> > +mbi_out->flags |= MBI_MEMMAP;
> > +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> > +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> > +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);
> > +mbi_out->mmap_length *= sizeof(*mmap_dst);
> > +
> > +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> > +
> > +mmap_src = get_mb2_data(tag, mmap, entries);
> > +mmap_dst = _p(mbi_out->mmap_addr);
> > +
> > +for ( i = 0; i < mbi_out->mmap_length / sizeof(*mmap_dst); i++
> > )
> > +{
> > +/* Init size member properly. */
> > +mmap_dst[i].size = sizeof(*mmap_dst);
> > +mmap_dst[i].size -= sizeof(mmap_dst[i].size);
> > +/* Now copy a given region data. */
> > +mmap_dst[i].base_addr_low = (u32)mmap_src->addr;
> > +mmap_dst[i].base_addr_high = (u32)(mmap_src->addr >> 32);
> > +mmap_dst[i].length_low = (u32)mmap_src->len;
> > +mmap_dst[i].length_high = (u32)(mmap_src->len >> 32);
> > +mmap_dst[i].type = mmap_src->type;
> > +mmap_src = _p(mmap_src) + get_mb2_data(tag, mmap,
> > entry_size);
> > +}
> > +break;
Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms
On Fri, Jan 20, 2017 at 02:34:35PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > > index 62c010e..c1285ad 100644 > > --- a/xen/arch/x86/efi/efi-boot.h > > +++ b/xen/arch/x86/efi/efi-boot.h > > > + > > +efi_exit_boot(ImageHandle, SystemTable); > > + > > +/* Return highest allocated memory address below 1 MiB. */ > > +return cfg.addr + cfg.size; > > So my comment about overwriting memory on 02/10 was spot on but made the > incorrect conclusion that it was before hand and not after. And here's > the issue. I believe what you meant to do was: > > return cfg.addr + MBI_SIZE; Errr... Sorry, this is the issue which I knew but I forgot to fix in v12. > I can't see how this booted for you with OVMF because for all the > different versions I've tried with the original code its writing over > reserved memory that QEMU uses for the graphics buffers. Which > immediately results in the trampolines being overwritten with console data. It booted without any complain... Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > Hi, > > > > I am sending twelfth version of multiboot2 protocol support for > > legacy BIOS and EFI platforms. This patch series release contains > > fixes for all known/confirmed issues. > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > get the following on some of the systems I have access to: > > (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > (XEN) [7.012109] Stuck ?? > (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > (XEN) [ 12.023606] Stuck ?? > (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > (XEN) [ 17.035099] Stuck ?? > (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > (XEN) [ 17.035116] Brought up 1 CPUs > > On other machines they reset when setting PAGING into cr0 (actually the > jmp following it) on line 124 of trampoline.S Thanks! I will take a look. > If I drop the series to just 2-5 against staging (since patch 1 has > already gone in) and apply the fix to efi_multiboot2() then all the > machines I presently have access to boot. Great! > Effectively the fix to efi_multiboot2() gets us back to the same level > of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > > Reviewed-by: Doug Goldstein > Tested-by: Doug Goldstein Thanks! > on the condition that the fix is applied to 5/10 prior to commit. Will do. By the way, I have asked my team colleagues to do more tests of this series. I will come back to you if I have something in hand. Thank you for your help. Have a nice weekend, Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On Sat, Jan 21, 2017 at 09:43:19AM +0800, Baoquan He wrote: > Hi, > > I don't strongly oppose against this, but could you tell what you have > met makes the kexec_loaded/kexec_crash_loaded checking not convenient to > you? kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash state. It does not say anything about Xen kexec/crash state. So, we need a special approach to get the latter. Though for compatibility we provide similar functionality in kexec-tools for the former. I hope that helps. > On 01/20/17 at 11:03am, Eric DeVolder wrote: > > Instead of the scripts having to poke at various fields we can > > provide that functionality via the -S parameter. > > > > Returns 0 if the payload is loaded. Can be used in combination > > with -l or -p to get the state of the proper kexec image. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > Signed-off-by: Eric DeVolder > > --- > > Note: The corresponding Xen changes have been committed > > to the Xen staging branch. Follow this thread: > > https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01570.html > > > > CC: Andrew Cooper > > CC: ke...@lists.infradead.org > > CC: xen-de...@lists.xenproject.org > > CC: Daniel Kiper > > > > v0: First version (internal product). > > v1: Posted on kexec mailing list. Changed -s to -S > > v2: Incorporated feedback from kexec mailing list > > --- > > configure.ac | 8 ++- > > kexec/kexec-xen.c | 26 +++ > > kexec/kexec.8 | 6 ++ > > kexec/kexec.c | 62 > > --- > > kexec/kexec.h | 5 - > > 5 files changed, 98 insertions(+), 9 deletions(-) > > > > diff --git a/configure.ac b/configure.ac > > index 3044185..c6e864b 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -165,8 +165,14 @@ fi > > dnl find Xen control stack libraries > > if test "$with_xen" = yes ; then > > AC_CHECK_HEADER(xenctrl.h, > > - [AC_CHECK_LIB(xenctrl, xc_kexec_load, , > > + [AC_CHECK_LIB(xenctrl, xc_kexec_load, [ have_xenctrl_h=yes ], > > AC_MSG_NOTICE([Xen support disabled]))]) > > +if test "$have_xenctrl_h" = yes ; then > > + AC_CHECK_LIB(xenctrl, xc_kexec_status, > > + AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1, > > + [The kexec_status call is available]), > > + AC_MSG_NOTICE([The kexec_status call is not available])) > > +fi Eric, I have a feeling that you should add en extra indentation for lines starting from "+if test "$have_xenctrl_h"..." and ending at "+fi". Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > > On 1/19/17 8:34 PM, Daniel Kiper wrote: > > > Hi, > > > > > > I am sending twelfth version of multiboot2 protocol support for > > > legacy BIOS and EFI platforms. This patch series release contains > > > fixes for all known/confirmed issues. > > > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > > get the following on some of the systems I have access to: > > > > (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > > (XEN) [7.012109] Stuck ?? > > (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > > (XEN) [ 12.023606] Stuck ?? > > (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > > (XEN) [ 17.035099] Stuck ?? > > (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > > (XEN) [ 17.035116] Brought up 1 CPUs > > > > On other machines they reset when setting PAGING into cr0 (actually the > > jmp following it) on line 124 of trampoline.S > > Thanks! I will take a look. > > > If I drop the series to just 2-5 against staging (since patch 1 has > > already gone in) and apply the fix to efi_multiboot2() then all the > > machines I presently have access to boot. > > Great! > > > Effectively the fix to efi_multiboot2() gets us back to the same level > > of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > > > > Reviewed-by: Doug Goldstein > > Tested-by: Doug Goldstein > > Thanks! > > > on the condition that the fix is applied to 5/10 prior to commit. > > Will do. > > By the way, I have asked my team colleagues to do more tests of this series. > I will come back to you if I have something in hand. Once you told me that you applied some patches on top of my patch series to get it working. Is it still true? If you still use some extra patches could you send me them? What about ExitBootServices() call? Did you disabled it? If yes on which machines it have to be disabled? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: > On 1/23/17 7:08 AM, Daniel Kiper wrote: > > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > >>> On 1/19/17 8:34 PM, Daniel Kiper wrote: > >>>> Hi, > >>>> > >>>> I am sending twelfth version of multiboot2 protocol support for > >>>> legacy BIOS and EFI platforms. This patch series release contains > >>>> fixes for all known/confirmed issues. > >>> > >>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > >>> get the following on some of the systems I have access to: > >>> > >>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > >>> (XEN) [7.012109] Stuck ?? > >>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > >>> (XEN) [ 12.023606] Stuck ?? > >>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > >>> (XEN) [ 17.035099] Stuck ?? > >>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > >>> (XEN) [ 17.035116] Brought up 1 CPUs > >>> > >>> On other machines they reset when setting PAGING into cr0 (actually the > >>> jmp following it) on line 124 of trampoline.S > >> > >> Thanks! I will take a look. > >> > >>> If I drop the series to just 2-5 against staging (since patch 1 has > >>> already gone in) and apply the fix to efi_multiboot2() then all the > >>> machines I presently have access to boot. > >> > >> Great! > >> > >>> Effectively the fix to efi_multiboot2() gets us back to the same level > >>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my: > >>> > >>> Reviewed-by: Doug Goldstein > >>> Tested-by: Doug Goldstein > >> > >> Thanks! > >> > >>> on the condition that the fix is applied to 5/10 prior to commit. > >> > >> Will do. > >> > >> By the way, I have asked my team colleagues to do more tests of this > >> series. > >> I will come back to you if I have something in hand. > > > > Once you told me that you applied some patches on top of my patch series to > > get > > it working. Is it still true? If you still use some extra patches could you > > send > > me them? What about ExitBootServices() call? Did you disabled it? If yes on > > which > > machines it have to be disabled? > > > > Daniel > > > > I previously used the patch that I linked to you authored by Konrad. I > have since switched to the patches that XenServer uses to no-op > efi_get_time() and to map additional ranges of reserved memory to make > EBS() work. Could you send me them? Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Mon, Jan 23, 2017 at 10:03:52AM -0600, Doug Goldstein wrote: > On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote: > > On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote: > >> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > >>>> On 1/19/17 8:34 PM, Daniel Kiper wrote: > >>>>> Hi, > >>>>> > >>>>> I am sending twelfth version of multiboot2 protocol support for > >>>>> legacy BIOS and EFI platforms. This patch series release contains > >>>>> fixes for all known/confirmed issues. > >>>> > >>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > >>>> get the following on some of the systems I have access to: > > > > Both me and Daniel seem to have test machines with EFI that are not soo .. > > defective. > > What machines? Model numbers? Manufacture? We are doing the tests. Until now everything works. I will compile full list for you when we are finished. > I'd also argue that this series continues to write into reserved memory > regions (as confirmed by the fix to 5/10 that I sent in) and you're able We do tests with your fix for #05 and full v12 patch series. > to still boot so I wouldn't put much value into the hardware you've been > using. I would not comment on that until I know why it does not work on your boxes. > > Could you mention which boxes have these kinds of trouble so we can > > get to the bottom of this? > > HP ML10v2 > Lenovo T430 > Intel NUC NUC5i5MYHE > Intel NUC NUC5i3MYHE (oddly has a pretty different firmware than above) > Mercury LDS3506 > Dell Precision 3420 (co-worker says this is setup to boot BIOS) > ASUS M3A78-CM motherboard > ASUS AMD motherboard (I don't have it near me and its not powered on > right now) > SuperMicro (I don't have it near me and its not powered on right > now so I can't figure it out) > QEMU + OVMF from Ubuntu 16.10 > QEMU (master from last week) + OVMF (master from last week) Thanks for the list. Do you use latest firmware on above mentioned machines? I hope that yes. I am asking just in case. I am going to release v13 by the end of Wednesday. Should I remove your Reviewed-by from patch 6-10? [...] > > And would it be possible to get serial/power access to this box (Intel NUC?) > > to figure out what is going on? > > Likely not. Both those operations are only available over AMT which is > connected on our internal corporate network. I can see if I can bring it > home for a period of time and give you access from my home. It would be nice. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support
On Mon, Jan 23, 2017 at 10:07:36AM -0600, Doug Goldstein wrote: > On 1/23/17 9:45 AM, Daniel Kiper wrote: > > On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote: > >> On 1/23/17 7:08 AM, Daniel Kiper wrote: > >>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote: > >>>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote: > >>>>> On 1/19/17 8:34 PM, Daniel Kiper wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I am sending twelfth version of multiboot2 protocol support for > >>>>>> legacy BIOS and EFI platforms. This patch series release contains > >>>>>> fixes for all known/confirmed issues. > >>>>> > >>>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I > >>>>> get the following on some of the systems I have access to: > >>>>> > >>>>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB > >>>>> (XEN) [7.012109] Stuck ?? > >>>>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5) > >>>>> (XEN) [ 12.023606] Stuck ?? > >>>>> (XEN) [ 12.023622] Failed to bring up CPU 2 (error -5) > >>>>> (XEN) [ 17.035099] Stuck ?? > >>>>> (XEN) [ 17.035115] Failed to bring up CPU 3 (error -5) > >>>>> (XEN) [ 17.035116] Brought up 1 CPUs > >>>>> > >>>>> On other machines they reset when setting PAGING into cr0 (actually the > >>>>> jmp following it) on line 124 of trampoline.S > >>>> > >>>> Thanks! I will take a look. > >>>> > >>>>> If I drop the series to just 2-5 against staging (since patch 1 has > >>>>> already gone in) and apply the fix to efi_multiboot2() then all the > >>>>> machines I presently have access to boot. > >>>> > >>>> Great! > >>>> > >>>>> Effectively the fix to efi_multiboot2() gets us back to the same level > >>>>> of hardware support that v11 + my v5 was at for 1-5. So I will extend > >>>>> my: > >>>>> > >>>>> Reviewed-by: Doug Goldstein > >>>>> Tested-by: Doug Goldstein > >>>> > >>>> Thanks! > >>>> > >>>>> on the condition that the fix is applied to 5/10 prior to commit. > >>>> > >>>> Will do. > >>>> > >>>> By the way, I have asked my team colleagues to do more tests of this > >>>> series. > >>>> I will come back to you if I have something in hand. > >>> > >>> Once you told me that you applied some patches on top of my patch series > >>> to get > >>> it working. Is it still true? If you still use some extra patches could > >>> you send > >>> me them? What about ExitBootServices() call? Did you disabled it? If yes > >>> on which > >>> machines it have to be disabled? > >>> > >>> Daniel > >> > >> I previously used the patch that I linked to you authored by Konrad. I > >> have since switched to the patches that XenServer uses to no-op > >> efi_get_time() and to map additional ranges of reserved memory to make > >> EBS() work. > > > > Could you send me them? > > > > Daniel > > I apply them only for 2 out of the roughly dozen machines. Its not those > changes. > > https://github.com/xenserver/xen-4.7.pg/blob/master/master/0002-efi-Ensure-incorrectly-typed-runtime-services-get-ma.patch > > https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-x86-time-Don-t-use-EFI-s-GetTime-call.patch Thanks! I will take a look. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote:
> Instead of the scripts having to poke at various fields we can
> provide that functionality via the -S parameter.
>
> kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash
> state. It does not say anything about Xen kexec/crash state. So,
> we need a special approach to get the latter. Though for
> compatibility we provide similar functionality in kexec-tools
> for the former.
>
> This change enables the --status or -S option to work either
> with or without Xen.
>
> Returns 0 if the payload is loaded. Can be used in combination
> with -l or -p to get the state of the proper kexec image.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Eric DeVolder
> ---
> Note: The corresponding Xen changes have been committed
> to the Xen staging branch. Follow this thread:
> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01570.html
>
> CC: Andrew Cooper
> CC: ke...@lists.infradead.org
> CC: xen-de...@lists.xenproject.org
> CC: Daniel Kiper
>
> v0: First version (internal product).
> v1: Posted on kexec mailing list. Changed -s to -S
> v2: Incorporated feedback from kexec mailing list, posted on kexec mailing
> list
> v3: Incorporated feedback from kexec mailing list
> ---
> configure.ac | 8 ++-
> kexec/kexec-xen.c | 26 +++
> kexec/kexec.8 | 6 ++
> kexec/kexec.c | 62
> ---
> kexec/kexec.h | 5 -
> 5 files changed, 98 insertions(+), 9 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 3044185..c6e864b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -165,8 +165,14 @@ fi
> dnl find Xen control stack libraries
> if test "$with_xen" = yes ; then
> AC_CHECK_HEADER(xenctrl.h,
> - [AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
> + [AC_CHECK_LIB(xenctrl, xc_kexec_load, [ have_xenctrl_h=yes ],
> AC_MSG_NOTICE([Xen support disabled]))])
> +if test "$have_xenctrl_h" = yes ; then
> + AC_CHECK_LIB(xenctrl, xc_kexec_status,
> + AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
> + [The kexec_status call is available]),
> + AC_MSG_NOTICE([The kexec_status call is not available]))
> +fi
I have a feeling that you have missed my comment. Please add two TABs
starting from "+if test "$have_xenctrl_h" = yes ; then" up to "+fi".
So, it should look more or less like this:
AC_MSG_NOTICE([Xen support disabled]))])
+ if test "$have_xenctrl_h" = yes ; then
+ AC_CHECK_LIB(xenctrl, xc_kexec_status,
...
If it is not needed or something like that please drop me a line.
> fi
>
> dnl ---Sanity checks
> diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c
> index 24a4191..2b448d3 100644
> --- a/kexec/kexec-xen.c
> +++ b/kexec/kexec-xen.c
> @@ -105,6 +105,27 @@ int xen_kexec_unload(uint64_t kexec_flags)
> return ret;
> }
>
> +int xen_kexec_status(uint64_t kexec_flags)
> +{
> + xc_interface *xch;
> + uint8_t type;
> + int ret = -1;
> +
> +#ifdef HAVE_KEXEC_CMD_STATUS
> + xch = xc_interface_open(NULL, NULL, 0);
> + if (!xch)
> + return -1;
> +
> + type = (kexec_flags & KEXEC_ON_CRASH) ? KEXEC_TYPE_CRASH :
> KEXEC_TYPE_DEFAULT;
> +
> + ret = xc_kexec_status(xch, type);
> +
> + xc_interface_close(xch);
> +#endif
> +
> + return ret;
> +}
> +
> void xen_kexec_exec(void)
> {
> xc_interface *xch;
> @@ -130,6 +151,11 @@ int xen_kexec_unload(uint64_t kexec_flags)
> return -1;
> }
>
> +int xen_kexec_status(uint64_t kexec_flags)
> +{
> + return -1;
> +}
> +
> void xen_kexec_exec(void)
> {
> }
> diff --git a/kexec/kexec.8 b/kexec/kexec.8
> index 4d0c1d1..f4b39a6 100644
> --- a/kexec/kexec.8
> +++ b/kexec/kexec.8
> @@ -107,6 +107,12 @@ command:
> .B \-d\ (\-\-debug)
> Enable debugging messages.
> .TP
> +.B \-S\ (\-\-status)
> +Return 0 if the type (by default crash) is loaded. Can be used in conjuction
> +with -l or -p to toggle the type. Note this option supersedes other options
> +and it will
> +.BR not\ load\ or\ unload\ the\ kernel.
Same as above. I think that you have missed my earlier comments.
I suppose that you can join "+and it will" and "+.BR not\ load\ or\
unload\ the\ kernel." into one line.
> +.TP
> .B \-e\ (\-\-exec)
> Run the currently loaded kernel. Note that it will reboot into the loaded
> kernel without calling shutdown(8).
> .TP
> diff --git a/kexec/ke
Re: [Xen-devel] [PATCH v3] kexec: implemented XEN KEXEC STATUS to determine if an image is loaded
On Tue, Jan 24, 2017 at 04:37:27PM -0600, Eric DeVolder wrote:
> On 01/24/2017 01:16 PM, Daniel Kiper wrote:
> >On Tue, Jan 24, 2017 at 12:55:35PM -0600, Eric DeVolder wrote:
[...]
> >>diff --git a/configure.ac b/configure.ac
> >>index 3044185..c6e864b 100644
> >>--- a/configure.ac
> >>+++ b/configure.ac
> >>@@ -165,8 +165,14 @@ fi
> >> dnl find Xen control stack libraries
> >> if test "$with_xen" = yes ; then
> >>AC_CHECK_HEADER(xenctrl.h,
> >>- [AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
> >>+ [AC_CHECK_LIB(xenctrl, xc_kexec_load, [ have_xenctrl_h=yes ],
> >>AC_MSG_NOTICE([Xen support disabled]))])
> >>+if test "$have_xenctrl_h" = yes ; then
> >>+ AC_CHECK_LIB(xenctrl, xc_kexec_status,
> >>+ AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
> >>+ [The kexec_status call is available]),
> >>+ AC_MSG_NOTICE([The kexec_status call is not available]))
> >>+fi
> >
> >I have a feeling that you have missed my comment. Please add two TABs
> >starting from "+if test "$have_xenctrl_h" = yes ; then" up to "+fi".
> >So, it should look more or less like this:
> >
> > AC_MSG_NOTICE([Xen support disabled]))])
> >+if test "$have_xenctrl_h" = yes ; then
> >+AC_CHECK_LIB(xenctrl, xc_kexec_status,
> >...
> >
> >If it is not needed or something like that please drop me a line.
>
> The tabs are not needed for the configure to work properly.
Yep.
> If tabs are needed for readability/style purposes, I will
> add them in. There is not any precedent of nesting in
Please do as above.
> the configure.ac file, so I am unsure what convention is
> for this package.
OK, no problem.
> >> fi
> >>
> >> dnl ---Sanity checks
> >>diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c
> >>index 24a4191..2b448d3 100644
> >>--- a/kexec/kexec-xen.c
> >>+++ b/kexec/kexec-xen.c
> >>@@ -105,6 +105,27 @@ int xen_kexec_unload(uint64_t kexec_flags)
> >>return ret;
> >> }
> >>
> >>+int xen_kexec_status(uint64_t kexec_flags)
> >>+{
> >>+ xc_interface *xch;
> >>+ uint8_t type;
> >>+ int ret = -1;
> >>+
> >>+#ifdef HAVE_KEXEC_CMD_STATUS
> >>+ xch = xc_interface_open(NULL, NULL, 0);
> >>+ if (!xch)
> >>+ return -1;
> >>+
> >>+ type = (kexec_flags & KEXEC_ON_CRASH) ? KEXEC_TYPE_CRASH :
> >>KEXEC_TYPE_DEFAULT;
> >>+
> >>+ ret = xc_kexec_status(xch, type);
> >>+
> >>+ xc_interface_close(xch);
> >>+#endif
> >>+
> >>+ return ret;
> >>+}
> >>+
> >> void xen_kexec_exec(void)
> >> {
> >>xc_interface *xch;
> >>@@ -130,6 +151,11 @@ int xen_kexec_unload(uint64_t kexec_flags)
> >>return -1;
> >> }
> >>
> >>+int xen_kexec_status(uint64_t kexec_flags)
> >>+{
> >>+ return -1;
> >>+}
> >>+
> >> void xen_kexec_exec(void)
> >> {
> >> }
> >>diff --git a/kexec/kexec.8 b/kexec/kexec.8
> >>index 4d0c1d1..f4b39a6 100644
> >>--- a/kexec/kexec.8
> >>+++ b/kexec/kexec.8
> >>@@ -107,6 +107,12 @@ command:
> >> .B \-d\ (\-\-debug)
> >> Enable debugging messages.
> >> .TP
> >>+.B \-S\ (\-\-status)
> >>+Return 0 if the type (by default crash) is loaded. Can be used in
> >>conjuction
> >>+with -l or -p to toggle the type. Note this option supersedes other options
> >>+and it will
> >>+.BR not\ load\ or\ unload\ the\ kernel.
> >
> >Same as above. I think that you have missed my earlier comments.
> >I suppose that you can join "+and it will" and "+.BR not\ load\ or\
> >unload\ the\ kernel." into one line.
>
> In that file, all dot directives start with the dot in the
> first column. I did the same for the .BR in this statement.
OK, let's leave it then.
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
