Re: RFC: A partition for grubenv, etc.

[Konrad Rzeszutek Wilk]

On Tue, May 25, 2021 at 04:58:23PM -0600, Chris Murphy wrote:
> Hi,
> 
> It's not possible for GRUB pre-boot environment to write to grubenv
> when it's on Btrfs, ZFS, LVM, mdadm raid, or LUKS. Also, at least XFS
> upstream is super skeptical of anything except kernel code making any
> kind of modification inside the file system region, and I suspect it's
> the same concern with ext4 developers too. While there are file system
> specific locations for bootloader usage, they're all different and
> quite small. XFS has none. ext4 has 512 bytes. Btrfs has maybe 1 or 2
> MiB, ZFS (?), mdadm (?) and LVM (?).

Aren't most distro setups using EFI which in effect means GRUB has to
deal most of the time with FAT32 file system? Does that work?

> 
> Proposal: A new partition type for MBR and GPT, functionally a
> replacement for the BIOS Boot partition, but it would be a partition
> owned by the bootloader for whatever it wants to use it for. It'd be
> up to the bootloader to figure out how to segment it for bootloader
> and environmental portions. We definitely need both MBR and GPT
> partition types, it should be a partition exclusively reserved for the
> bootloader. This effectively deprecates the use of the MBR gap, and
> BIOS Boot partition types, and further it deprecates the use of file
> systems (all of them, for consistency sake) for the use of grubenv.
> 
> Variation: Keep BIOS Boot and repurpose it to include grubenv, while
> also specifying an MBR type code for its equivalent.
> 
> 
> Use case: For example, Fedora has a "hidden grub menu" feature where
> by a variable in grubenv is reset (written to) by grub pre-boot. And
> then a systemd unit changes that variable to indicate a successful
> boot once some time and/or tests have been met. If grubenv indicates
> successful boot, the next boot's grub menu is hidden. If it wasn't
> successful the next boot's grub menu is displayed. It's only possible
> to achieve this with some reliable bidirectional way of communicating
> between the preboot and booted environments, which is the point of
> grubenv, but it can't work much of the time due to the above
> limitations.
> 
> -- 
> Chris Murphy
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>)

[Konrad Rzeszutek Wilk]

..snip..
> I'm less concerned with the capabilities of other clients than I am for
> how this negatively impacts the current workflow of people on this
> list, which is what I'm trying to figure out. How does doing this
> making things more difficult for people here? And specifically Daniel.

Don't know what flow Daniel is using, but my email reader is mutt.

Once I am comfortable with the patches I usually save them in a mailbox
(.mbox) and do 'git am -s' on them and then kickoff a workflow.

Having multiple threads within threads makes my life as maintainer
more difficult as I have to manually split out the right version and
save it.

I suppose I can use the 'tag-save' option and save the ones
with a certain version to a mailbox which can add another step in this.
And then I am worried I missed something :-(

> 
> If this causes tools to break, then that's certainly a good reason to
> avoid changing things. If it makes Daniel's workflow more burdensome
> because he has a client that can not collapse threads at all, then
> that's a valid concern too. I'm currently failing to see as valid
> concerns: "because traditionally we've never done it that way" or "I
> don't like seeing patchset revisions together".
> 
> From a structuring data point of view, it makes more sense (to me) to
> link patchset revisions together. Now it might also be true that
> looking at previous patchsets is very uncommon and so its not a huge

Maintainers trust that folks add right after the ---

v6: Fixed up spaces
Fixed up XYZ

and there is no need to go back to v5 or earlier.

> benefit to link them together. But that's not a reason why it shouldn't
> be done.

So ... making the life of maintainer and as simple as possible makes
it easier and faster to get patches upstream.

That is what LKML has taught a lot of us and that is probably why
many of us are used to this workflow.

> 
> Perhaps with a better understanding of the harm, I could come to a
> different opinion. And sincerely, thank you for the feedback.
> 
> Glenn
> 
> > Kind regards,
> > 
> > Paul
> > 
> > 
> > [1]:
> > https://lists.gnu.org/archive/html/grub-devel/2021-03/threads.html
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: RFC: Grub project management

[Konrad Rzeszutek Wilk]

On Thu, Feb 11, 2021 at 09:53:37PM -0600, Glenn Washburn wrote:
> Hi fellow GRUB developers,
> 
> I want to start by recognizing that most people who are involved with
> the project maintenance are doing so on a voluntary basis (or at least
> that's my assumption) and people have busy lives. Its a mostly
> thankless job, so thank you guys for all the time spent keeping this
> essential project alive. I hope that the following will not be construed
> as judging anyone, but merely taking account of where we've been, where
> we are, and how to move forward.

So .. May I take your email and break it down?
> 
> TLDR; Check out https://gitlab.com/gnu-grub/grub and do merge requests
> with changes rebased on to feature/gitlab-testing against
> feature/gitlab-testing to get automatic CI testing.
> 
> I believe I speak for more than just myself when I say that the current
> development process leaves much to be desired. GRUB has been in a
> feature freeze since last March, with the release being pushed
> rescheduled several times and now looks like its projected to be in
> March (assuming its not pushed back again). I get the impression that
> Daniel is overloaded with non-GRUB responsibilities. I also wonder if
> part of the issue is concerned about making a release which he believes
> hasn't had sufficient testing.
> 
> Daniel, could you please clarify what needs to be done to get the
> release out the door and what the community can do to help expedite
> this process?

What I am understanding is that Daniel is the bottlenck here. That is
his reviews of patches (and fixes up) are what is holding up the
acceptance?

> 
> In the meantime, patches are being sent to the list which will not be
> considered for acceptance until the release is out and feature freeze
> lifted. Does anyone believe that someone is going to go back to last
> March and check all the submitted patches to see about including them?

Daniel (from the years I have worked with him) is very detailed
person who has a nice workflow to make sure they are there.

> I judge the answer to be no. So patches will be continually falling
> into a blackhole. What we need is an issue/merge management system so

Do you have an example of a particular patchset that went into a
blackhole?

> things don't get lost, or can easily be found.

I would assume that folks who care about their patches would repost once
the release goes out?

Is this why the GitLab came about - as a way to keep track of patches
that need review?

> 
> GRUB currently uses the Savannah GNU project hosting site. And while I
> love GNU philosophy and the role that Savannah has played for free
> software projects, it is showing its age and not ideal for a modern
> development process. My two big pain points is that it does not do
> merge requests and the bug tracker is an unpleasant experience when
> compared to modern ones. If you've ever tried to search for a bug,
> you'll know what I mean. So unfortunately, I think its time to say

It is a feature. We got no bugs :-)

> goodbye Savannah.

But the merge requests are not the pain points. It is reviewing the
patches I would think?
> 
> Another issue, as I see it, is the testing. The only testing that I'm
> aware of is the travis CI, which is only a build test, and Adrian's
> testing for debian, which does do the make check tests but is missing
> filesystem testing and qemu tests for most architectures. Ideally, the
> make check tests should be done within travis, but we're not there yet.
> This process feels closed and non-transparent to me, which I find
> undesirable in general, but especially so for a free software project
> which is the corner-stone of the linux community. And I'm not saying
> that that is intentional on the part of those working on those tests.
> So, for one, it would be nice to have publicly accessible the status of
> Travis runs. And may be it is, but why isn't it obvious?

As you point out the Travis CI is for build tests which is not that
exciting. I think what you are really saying is that you want better
tests?
> 
> Based on what I've gathered from the list and private conversations
> (which isn't much), the travis is only really run as a prep for making
> a release. If that's true, the process fails to use the main point of a
> continuous integration system. I would like GRUB to get to a place
> where every commit is run through CI (at least the build test). In the
> short term, it would be nice to kick off a CI job every time master
> changes.

So I agree it is nice, but I am missing how this is going to help
in getting a release out faster?

> 
> It would be even more nice if we could integrate the merge tracking
> system with the CI system so that merge requests automatically kick off
> a CI job to see if the proposed changes pass both the build test and
> functional make check tests.

Ah, so it fixes the simple compile issues patches may have!
> 
> I believe, and my sincere hope, is that by resolving these 

Re: [PATCH] Remove unnecessary constraints on required_pages for EFI boot

[Konrad Rzeszutek Wilk]

On January 10, 2021 2:41:09 PM EST, "Char, Hanson via Grub-devel" 
 wrote:
>As reported earlier, when booted in UEFI mode, Grub would fail to load
>a ramdisk of size larger than "(total_pages >> 2)" with
>
>    "error: out of memory"
>
>(https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/kern/efi/mm.c#n616)
>
>Further investigation into the EFI memory map indicates the current
>limit of MAX_HEAP_MEMORY and the use of a quarter of the total_pages
>returned from EFI available memory (type 7) as the default seems
>arbitrary and unnecessary.
>
>Therefore this proposed patch removes the aribrary limit, and lets Grub
>make full use of the EFI available memory reported by the BIOS.
>
>The patch has been successfully tested to load large ramdisk with size
>that would otherwise fail.
>


Something  is off with your patch. That text above should have been in the 
patch as a comment. And also your SoB in it. Could you kindly repost?


>Regards,
>Hanson
>
>From ceb27404eb281a74aa82799885cd74b530e9237e Mon Sep 17 00:00:00 2001
>From: Hanson Char 
>Date: Sun, 10 Jan 2021 10:57:06 -0800
>Subject: [PATCH] Remove unnecessary constraints on required_pages for
>EFI boot
>
>---
> grub-core/kern/efi/mm.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
>diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
>index 457772d57..9cf6a4d34 100644
>--- a/grub-core/kern/efi/mm.c
>+++ b/grub-core/kern/efi/mm.c
>@@ -38,9 +38,8 @@
>    a multiplier of 4KB.  */
> #define MEMORY_MAP_SIZE    0x3000
>
>-/* The minimum and maximum heap size for GRUB itself.  */
>+/* The minimum heap size for GRUB itself.  */
> #define MIN_HEAP_SIZE  0x10
>-#define MAX_HEAP_SIZE  (1600 * 0x10)
>
> static void *finish_mmap_buf = 0;
> static grub_efi_uintn_t finish_mmap_size = 0;
>@@ -569,7 +568,6 @@ grub_efi_mm_init (void)
>   grub_efi_memory_descriptor_t *filtered_memory_map_end;
>   grub_efi_uintn_t map_size;
>   grub_efi_uintn_t desc_size;
>-  grub_efi_uint64_t total_pages;
>   grub_efi_uint64_t required_pages;
>   int mm_status;
>
>@@ -610,14 +608,10 @@ grub_efi_mm_init (void)
>   filtered_memory_map_end = filter_memory_map (memory_map,
>filtered_memory_map,
>                           desc_size, memory_map_end);
>
>-  /* By default, request a quarter of the available memory.  */
>-  total_pages = get_total_pages (filtered_memory_map, desc_size,
>-                filtered_memory_map_end);
>-  required_pages = (total_pages >> 2);
>+  required_pages = get_total_pages (filtered_memory_map, desc_size,
>+                                    filtered_memory_map_end);
>   if (required_pages < BYTES_TO_PAGES (MIN_HEAP_SIZE))
>     required_pages = BYTES_TO_PAGES (MIN_HEAP_SIZE);
>-  else if (required_pages > BYTES_TO_PAGES (MAX_HEAP_SIZE))
>-    required_pages = BYTES_TO_PAGES (MAX_HEAP_SIZE);
>
>   /* Sort the filtered descriptors, so that GRUB can allocate pages
>      from smaller regions.  */
>--
>2.29.2
>
>___
>Grub-devel mailing list
>Grub-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/grub-devel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [GRUB RFC PATCH 00/22] i386: Intel TXT and AMD SKINIT secure launcher

[Konrad Rzeszutek Wilk]

On Tue, Nov 10, 2020 at 03:44:38PM +0100, Krystian Hebel wrote:
> Hi,
> 
> This is an addition to the RFC patchset which introduced TrenchBoot support 
> for
> Intel TXT.
> 
> It includes all original patches sent by Daniel Kiper back in May, rebased on

So .. if they are Daniel's should this..
> Krystian Hebel (4):
>   i386/slaunch: Add code for searching for DRTM event log in ACPI
>   i386/skinit: Add AMD SKINIT definitions header file
>   i386/skinit: Add AMD SKINIT core implementation
>   i386/slaunch: Add support for AMD SKINIT
> 
> Norbert Kaminski (18):
>   i386/msr: Merge rdmsr.h and wrmsr.h into msr.h
>   i386/msr: Rename grub_msr_read() and grub_msr_write()
>   i386/msr: Extract and improve MSR support detection code
>   i386/memory: Rename PAGE_SHIFT to GRUB_PAGE_SHIFT
>   i386/memory: Rename PAGE_SIZE to GRUB_PAGE_SIZE and make it global
>   mmap: Add grub_mmap_get_lowest() and grub_mmap_get_highest()
>   i386/tpm: Rename tpm module to tpm_verifier
>   i386/tpm: Add TPM TIS and CRB driver
>   efi: Make shim_lock GUID and protocol type public
>   efi: Return grub_efi_status_t from grub_efi_get_variable()
>   efi: Add a function to read EFI variables with attributes
>   i386/efi: Report UEFI Secure Boot status to the Linux kernel
>   i386/slaunch: Add basic platform support for secure launch
>   i386/txt: Add Intel TXT definitions header file
>   i386/txt: Add Intel TXT core implementation
>   i386/txt: Add Intel TXT ACM module support
>   i386/txt: Add Intel TXT verification routines
>   i386/slaunch: Add secure launch framework and commands

.. have Daniel's name on them?

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 08/18] libtasn1: import libtasn1-4.16.0

[Konrad Rzeszutek Wilk]

On Fri, Oct 02, 2020 at 03:13:11PM +1000, Daniel Axtens wrote:
> Import a very trimmed-down set of libtasn1 files:
> 
> pushd /tmp
> wget https://ftp.gnu.org/gnu/libtasn1/libtasn1-4.16.0.tar.gz
> popd
> pushd grub-core/lib
> mkdir libtasn1
> cp /tmp/libtasn1-4.16.0/{README.md,LICENSE} libtasn1/
> mkdir libtasn1/lib
> cp 
> /tmp/libtasn1-4.16.0/lib/{coding.c,decoding.c,element.c,element.h,errors.c,gstr.c,gstr.h,int.h,parser_aux.c,parser_aux.h,structure.c,structure.h}
>   libtasn1/lib
> cp /tmp/libtasn1-4.16.0/lib/includes/libtasn1.h ../../include/grub/
> git add libtasn1/ ../../include/grub/libtasn1.h
> popd
> 
> Signed-off-by: Daniel Axtens 
> ---
>  grub-core/lib/libtasn1/LICENSE  |   16 +
>  grub-core/lib/libtasn1/README.md|   91 +
>  grub-core/lib/libtasn1/lib/coding.c | 1415 +
>  grub-core/lib/libtasn1/lib/decoding.c   | 2478 +++
>  grub-core/lib/libtasn1/lib/element.c|  ++
>  grub-core/lib/libtasn1/lib/element.h|   40 +
>  grub-core/lib/libtasn1/lib/errors.c |  100 +
>  grub-core/lib/libtasn1/lib/gstr.c   |   74 +
>  grub-core/lib/libtasn1/lib/gstr.h   |   47 +
>  grub-core/lib/libtasn1/lib/int.h|  221 ++
>  grub-core/lib/libtasn1/lib/parser_aux.c | 1173 +++
>  grub-core/lib/libtasn1/lib/parser_aux.h |  172 ++
>  grub-core/lib/libtasn1/lib/structure.c  | 1220 +++
>  grub-core/lib/libtasn1/lib/structure.h  |   45 +
>  include/grub/libtasn1.h |  588 ++
>  15 files changed, 8791 insertions(+)
>  create mode 100644 grub-core/lib/libtasn1/LICENSE
>  create mode 100644 grub-core/lib/libtasn1/README.md
>  create mode 100644 grub-core/lib/libtasn1/lib/coding.c
>  create mode 100644 grub-core/lib/libtasn1/lib/decoding.c
>  create mode 100644 grub-core/lib/libtasn1/lib/element.c
>  create mode 100644 grub-core/lib/libtasn1/lib/element.h
>  create mode 100644 grub-core/lib/libtasn1/lib/errors.c
>  create mode 100644 grub-core/lib/libtasn1/lib/gstr.c
>  create mode 100644 grub-core/lib/libtasn1/lib/gstr.h
>  create mode 100644 grub-core/lib/libtasn1/lib/int.h
>  create mode 100644 grub-core/lib/libtasn1/lib/parser_aux.c
>  create mode 100644 grub-core/lib/libtasn1/lib/parser_aux.h
>  create mode 100644 grub-core/lib/libtasn1/lib/structure.c
>  create mode 100644 grub-core/lib/libtasn1/lib/structure.h
>  create mode 100644 include/grub/libtasn1.h
> 
> diff --git a/grub-core/lib/libtasn1/LICENSE b/grub-core/lib/libtasn1/LICENSE
> new file mode 100644
> index ..e8b3628db9b8
> --- /dev/null
> +++ b/grub-core/lib/libtasn1/LICENSE
> @@ -0,0 +1,16 @@
> +LICENSING
> +=
> +
> +The libtasn1 library is released under the GNU Lesser General Public
> +License (LGPL) version 2.1 or later; see [COPYING.LESSER](doc/COPYING.LESSER)
> +for the license terms.
> +
> +The GNU LGPL applies to the main libtasn1 library, while the
> +included applications library are under the GNU GPL version 3.
> +The libtasn1 library is located in the lib directory, while the applications
> +in src/.

GRUB is GPL-v3. This is not.

Can you re-license it to be GPL-v3?


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Submit patch/changes for Multiboot Documentation

[Konrad Rzeszutek Wilk]

On Sat, Sep 26, 2020 at 09:11:53AM +0100, Chris Plant wrote:
> Hello,
> 
> Might be a stupid question, but how do I submit/propose changes to the
> multiboot specification itself? 
> 
> Should I just update the texinfo source from the website and attach
> that to my patch?

Yes please. And make sure you answer 'why' this is needed and provide
your Signed-off-by (see https://developercertificate.org/).

Thank you.
> 
> Thanks,
> 
> Chris
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 3/3] Add tests for cmdline module

[Konrad Rzeszutek Wilk]

On Fri, Jun 12, 2020 at 05:14:23PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> -- 
> Regards
> Vladimir 'phcoder' Serbinenko


>From 69e11c5a68e75c9f48953e320cddbdf3e7f9eb46 Mon Sep 17 00:00:00 2001
>From: Vladimir Serbinenko 
>Date: Fri, 12 Jun 2020 17:09:44 +0200
>Subject: [PATCH 3/3] Add tests for cmdline module
>
>Signed-off-by: Vladimir Serbinenko 
>---
> grub-core/Makefile.core.def   | 12 +
> grub-core/tests/loader_cmdline_test.c | 69 +++
> 2 files changed, 81 insertions(+)
> create mode 100644 grub-core/tests/loader_cmdline_test.c
>
>diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>index 166b444c7..5038e03be 100644
>--- a/grub-core/Makefile.core.def
>+++ b/grub-core/Makefile.core.def
>@@ -1823,6 +1823,13 @@ module = {
>   enable = noemu;
> };
> 
>+/* Special case for emu so we always have cmdline available for the tests.  */
>+module = {
>+  name = cmdline_lib;
>+  common = lib/cmdline.c;
>+  enable = emu;
>+};
>+
> module = {
>   name = fdt;
>   efi = loader/efi/fdt.c;
>@@ -2119,6 +2126,11 @@ module = {
>   common = tests/strtoull_test.c;
> };
> 
>+module = {
>+  name = loader_cmdline_test;
>+  common = tests/loader_cmdline_test.c;
>+};
>+
> module = {
>   name = setjmp_test;
>   common = tests/setjmp_test.c;
>diff --git a/grub-core/tests/loader_cmdline_test.c 
>b/grub-core/tests/loader_cmdline_test.c
>new file mode 100644
>index 0..c3f6bcebe
>--- /dev/null
>+++ b/grub-core/tests/loader_cmdline_test.c
>@@ -0,0 +1,69 @@
>+/*
>+ *  GRUB  --  GRand Unified Bootloader
>+ *  Copyright (C) 2013  Free Software Foundation, Inc.

2013?


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 0/3] cmdline fixes for acpi_osi

[Konrad Rzeszutek Wilk]

On Fri, Jun 12, 2020 at 05:12:42PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> This patch series introduces an escaping of spaces that is compatible
> with linux parameter parsing. Also it adds some needed tests for this
> part of code

For easy review could you please in the future send it using git-send-email?

Thanks!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] grub.d: Use linuxefi and initrdefi commands if platform is efi

[Konrad Rzeszutek Wilk]

On Wed, Mar 25, 2020 at 06:38:54PM +0100, Daniel Kiper wrote:
> On Mon, Mar 23, 2020 at 07:53:15PM +0800, Tianjia Zhang wrote:
> > When the platform is EFI platform, use 'linuxefi' and 'initrdefi'
> > commands instead of 'linux' and 'initrd'.
> >
> > Signed-off-by: Jia Zhang 
> > Signed-off-by: Tianjia Zhang 
> 
> Sorry, NAK! We do not want more "linuxefi" kinda commands in the GRUB 
> upstream.

Are you saying that the existing 'linux' and 'initrd' should be fixed
to work under EFI?

Thanks.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v3 3/5] argon2: Import Argon2 from cryptsetup

[Konrad Rzeszutek Wilk]

On Mon, Mar 16, 2020 at 06:21:06PM +0100, Daniel Kiper wrote:
> On Fri, Mar 13, 2020 at 02:13:49PM +0100, Daniel Kiper wrote:
> > On Tue, Mar 10, 2020 at 07:58:30PM +0100, Patrick Steinhardt wrote:
> > > In order to support the Argon2 key derival function for LUKS2, we
> > > obviously need to implement Argon2. It doesn't make a lot of sense to
> > > hand-code any crypto, which is why this commit instead imports Argon2
> > > from the cryptsetup project. This commit thus imports the code from the
> > > official reference implementation located at [1]. The code is licensed
> > > under CC0 1.0 Universal/Apache 2.0. Given that both LGPLv2.1+ and Apache
> > > 2.0 are compatible with GPLv3, it should be fine to import that code.
> > >
> > > The code is imported from commit 62358ba (Merge pull request #270 from
> > > bitmark-property-system/master, 2019-05-20). To make it work for GRUB,
> > > several adjustments were required that have beed documented in
> > > "grub-dev.texi".
> > >
> > > [1]: https://github.com/P-H-C/phc-winner-argon2
> > >
> > > Signed-off-by: Patrick Steinhardt 
> >
> > [...]
> >
> > > diff --git a/grub-core/lib/argon2/argon2.c b/grub-core/lib/argon2/argon2.c
> > > new file mode 100644
> > > index 0..c77f7f6ff
> > > --- /dev/null
> > > +++ b/grub-core/lib/argon2/argon2.c
> > > @@ -0,0 +1,232 @@
> > > +/*
> > > + * Argon2 reference source code package - reference C implementations
> > > + *
> > > + * Copyright 2015
> > > + * Daniel Dinu, Dmitry Khovratovich, Jean-Philippe Aumasson, and Samuel 
> > > Neves
> > > + *
> > > + * You may use this work under the terms of a Creative Commons CC0 1.0
> > > + * License/Waiver or the Apache Public License 2.0, at your option. The 
> > > terms of
> > > + * these licenses can be found at:
> > > + *
> > > + * - CC0 1.0 Universal : http://creativecommons.org/publicdomain/zero/1.0
> > > + * - Apache 2.0: http://www.apache.org/licenses/LICENSE-2.0
> > > + *
> > > + * You should have received a copy of both of these licenses along with 
> > > this
> > > + * software. If not, they may be obtained at the above URLs.
> > > + */
> > > +
> > > +#include 
> > > +
> > > +#include "argon2.h"
> > > +#include "core.h"
> > > +
> > > +GRUB_MOD_LICENSE ("GPLv3");
> >
> > I think we should change that if the license above is different.
> > Anyway, I am trying to get in touch with FSF license team. I have not
> > got a reply yet... I will see what is possible in my company...
> 
> Got an unofficial reply that we cannot remove current license from the
> Argon2 reference source code package. However, we can add GPLv3 header
> after current license header. Hence, I would suggest heading in that
> direction. Still waiting for final confirmation. Sadly usual turn around
> is about two weeks...

Sorry for asking this so late- but has anybody tried contacting the authors
(Daniel Dinu, Dmitry Khovratovich, Jean-Philippe Aumasson, and Samuel Neves) and
asking if they would be willing to post their code under GPL-v3?

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB 2.04 freeze date announcement

[Konrad Rzeszutek Wilk]

On Tue, Mar 12, 2019 at 01:22:30PM +0100, Daniel Kiper wrote:
> Hi,
> 
> On Fri, Mar 01, 2019 at 12:31:40PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> > Hello everyone!
> >
> > We are happy to announce that the upcoming release of Grub 2.04 is expected
> > in March. In order to prepare the release we would freeze on Monday, March

March 30th? So tarballs on April 1st :-)
> > 11, 23:59:59 UTC. From that point no new features are accepted unless there
> > is a very good reason to. We will still accept bugfixes. In fact we kindly
> > ask to test systems and features you care about
> 
> Just a kind reminder that freeze is in force now. Only fixes will be
> accepted. All features will be reviewed if time allows but will be
> committed after the release.
> 
> Daniel
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add travis-ci config file

[Konrad Rzeszutek Wilk]

On Tue, Feb 12, 2019 at 06:00:33PM +0100, Alexander Graf wrote:
> There is a really convenient service for open source project from Travis
> CI: They allow for free CI testing using their infrastructure.
> 
> Grub has had issues with broken builds for various targets for a long time
> already. The main reason is a lack of CI to just do smoke tests on whether
> all targets still at least compile.
> 
> This patch adds a travis config file which builds (almost) all currently
> available targets.
> 
> On top of that, this travis config also runs a small execution test on the
> x86_64-efi target.
> 
> All of this config file can easily be extended further on. It probably makes
> sense to do something similar to the u-boot test infrastructure that
> communicates with the payload properly. Going forward, we also will want to
> do more qemu runtime checks for other targets.
> 
> Currently, with this config alone, I already see about half of the available
> targets as broken. So it's definitely desperately needed :).

This is awesome.. However is grub on github to automatically kick of CI ?
> 
> Signed-off-by: Alexander Graf 
> ---
>  .travis.yml | 118 
> 
>  1 file changed, 118 insertions(+)
>  create mode 100644 .travis.yml
> 
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 0..05608fc21
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,118 @@
> +# SPDX-License-Identifier: GPL-3.0+
> +# Originally Copyright Roger Meier 
> +# Adapted for grub by Alexander Graf 
> +
> +# build grub on Travis CI - https://travis-ci.org/
> +
> +dist: xenial
> +
> +language: c
> +
> +addons:
> +  apt:
> +packages:
> +- cppcheck
> +- sloccount
> +- sparse
> +- bc
> +- build-essential
> +- libsdl1.2-dev
> +- python
> +- python-virtualenv
> +- swig
> +- libpython-dev
> +- iasl
> +- rpm2cpio
> +- wget
> +- device-tree-compiler
> +- lzop
> +- liblz4-tool
> +- libisl15
> +- qemu-system
> +- ovmf
> +- unifont
> +
> +env:
> +  global:
> +- 
> PATH=/tmp/qemu-install/bin:/tmp/grub/bin:/usr/bin:/bin:/tmp/cross/gcc-8.1.0-nolibc/aarch64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/arm-linux-gnueabi/bin:/tmp/cross/gcc-8.1.0-nolibc/ia64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/mips64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/powerpc64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv32-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/riscv64-linux/bin:/tmp/cross/gcc-8.1.0-nolibc/sparc64-linux/bin
> +
> +before_script:
> +  # install toolchains based on TOOLCHAIN} variable
> +  - mkdir /tmp/cross
> +  # results in binaries like 
> /tmp/cross/gcc-8.1.0-nolibc/ia64-linux/bin/ia64-linux-gcc
> +  - for i in $CROSS_TARGETS; do
> +( cd /tmp/cross; wget -O - 
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-$i.tar.xz
>  | xzcat | tar x );
> +done
> +
> +script:
> +  # Comments must be outside the command strings below, or the Travis parser
> +  # will get confused.
> +  - ./autogen.sh
> +
> +  # Build all selected grub targets:
> +  - for target in $GRUB_TARGETS; do
> +  plat=${target#*-};
> +  arch=${target%-*};
> +  [ "$arch" = "arm64" ] && arch=aarch64-linux;
> +  [ "$arch" = "arm" ] && arch=arm-linux-gnueabi;
> +  [ "$arch" = "ia64" ] && arch=ia64-linux;
> +  [ "$arch" = "mipsel" ] && arch=mips64-linux;
> +  [ "$arch" = "powerpc" ] && arch=powerpc64-linux;
> +  [ "$arch" = "riscv32" ] && arch=riscv32-linux;
> +  [ "$arch" = "riscv64" ] && arch=riscv64-linux;
> +  [ "$arch" = "sparc64" ] && arch=sparc64-linux;
> +  echo "Building $target";
> +  mkdir obj-$target;
> +  ( cd obj-$target && ../configure --target=$arch --with-platform=$plat 
> --prefix=/tmp/grub && make -j4 && make -j4 install ) &> log || ( cat log; 
> false );
> +done
> +
> +  # Our test canary
> +  - echo -e "insmod echo\\ninsmod reboot\\necho hello world\\nreboot" > 
> grub.cfg
> +
> +  # Assemble images and possibly run them
> +  - for target in $GRUB_TARGETS; do grub-mkimage -c grub.cfg -p / -O $target 
> -o grub-$target echo reboot normal; done
> +
> +  # Run images we know how to run
> +  - if [[ "$GRUB_TARGETS" == *"x86_64-efi"* ]]; then qemu-system-x86_64 
> -bios /usr/share/ovmf/OVMF.fd -m 512 -no-reboot -nographic -net nic -net 
> user,tftp=.,bootfile=grub-x86_64-efi | tee grub.log && grep "hello world" 
> grub.log; fi
> +
> +matrix:
> +  include:
> +  # each env setting here is a dedicated build
> +- name: "x86_64"
> +  env:
> +- GRUB_TARGETS="x86_64-efi x86_64-xen"
> +- name: "i386"
> +  env:
> +- GRUB_TARGETS="i386-efi i386-xen i386-xen_pvh i386-pc 
> i386-multiboot i386-coreboot i386-ieee1275 i386-qemu"
> +- name: "powerpc"
> +  env:
> +- GRUB_TARGETS="powerpc-ieee1275"
> +- CROSS_TARGETS=powerpc64-linux"
> +- name: "sparc64"
> +  env:
> +- 

Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

[Konrad Rzeszutek Wilk]

On Sun, Nov 11, 2018 at 10:49:39AM -0800, H. Peter Anvin wrote:
> On 11/10/18 1:03 AM, Juergen Gross wrote:
> > 
> > How would that help? The garabge data written could have the correct
> > terminal sentinel value by chance.
> > 
> > That's why I re-used an existing field in setup_header (the version) to
> > let grub tell the kernel which part of setup_header was written by grub.
> > 
> > That's the only way I could find to let the kernel distinguish between
> > garbage and actual data.
> 
> There is plenty of space *before* the setup_header part of struct boot_params
> too -- look a the various __pad fields, especially (in your case), __pad3[16]
> and __pad4[116] would suit the bill just fine.
> 
> >> It would be enormously helpful if you could find out any more details about
> >> exactly what they are doing to break things.
> > 
> > That's easy:
> > 
> > The memory layout is:
> > 
> > 0x1f1 bytes of data, including the sentinel, the setup_header, and then
> > more data.
> > 
> > grub did read the kernel's setup_header in the correct size into its
> > buffer (which contains random garbage before that), intializes the first
> > 0x1f1 including the sentinel byte, and then writes back the buffer, but
> > using a too large length for that.
> 
> Are you kidding me... it really overwrites it with completely random data, and
> not simply overspilling contents of the file?
> 
> In that case it might not be possible (or desirable) to use those N bytes
> following the setup_heaader, or we need to a bigger sentinel than one byte
> (probability being what it is, 256^n gets to be a pretty big number for any n,
> very quickly drowning in the noise compared to other potential sources of boot
> failures, and most likely less fatal than most.)
> 
> How big is this garbage dump?  I'm going to brave a guess it is 512 bytes.  In
> that case this is hardly a big deal: the E820 map begins at 0x290, and the
> setup_header maximum goes to 0x280, so it is only 15 bytes lost.  If it is
> worse than that, we would risk losing __pad8[48] and __pad9[276], and
> especially the latter would be painful. In those case perhaps we should use
> 0x281..0x290 as a 15-byte sentinel; that is going to be virtually foolproof.
> 
> I'm also thinking that it might be desirable to add a flags field (__pad2
> would be ideal) to struct boot_params; it would let us recycle some of the
> obsolete fields (hd0_info, hd1_info, sys_desc_table, olpc_ofw_header, ...) and
> perhaps be able to add some more robustness against these sort of things. This
> would be the right way to do what your version feedback mechanism would do.
> 
> The reason why the feedback mechanism is fundamentally broken is that it only
> gives the boot loader a way to assert that it supports a certain version of
> the protocol, but it doesn't say *which* bootloader does such an assert -- and
> therefore it is still wide open to implementation error.
> 
> We do, in fact, already have a feedback mechanism: the bootloader ID and
> bootloader version. One way we could deal with this problem is to bump the
> bootloader version reported by Grub, and add a quirk to the kernel that if the
> bootloader ID is Grub (7) and the version is less than a certain number, zero
> those fields. In fact, the more I think about it, this is what we should do.
> 
> That being said, Grub really needs to be kept honest.  They keep making both
> severe design (like refusing to use the BIOS and UEFI entry points provided by
> the kernel by default) and implementation errors, apparently without
> meaningful oversight. I really ask that the people more closely involved with
> Grub try to keep a closer eye on their code as it applies to Linux.

Cc-ing GRUB and Daniel Kiper (maintainer of GRUB).

Could folks please please CC Daniel Kiper on any of these patches in the future?

Thanks.
> 
>   -hpa

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v3 5/8] verifiers: Rename verify module to pgp module

[Konrad Rzeszutek Wilk]

> 
> I did "git mv" but "git format-patch" produced this. I am not sure that
> "git format-patch" is sufficiently smart to produce shorter stuff.

Look at the -M param for git format-patch.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Multiboot ELF segment handling patch

[Konrad Rzeszutek Wilk]

On April 17, 2018 3:40:11 PM EDT, Daniel Kiper  wrote:
>Hi Alexander,
>
>On Sat, Apr 14, 2018 at 12:07:29AM +0200, Alexander Boettcher wrote:
>> Hello,
>>
>> On 06.04.2018 14:28, Daniel Kiper wrote:
>> > On Thu, Mar 29, 2018 at 11:20:37AM +0200, Alexander Boettcher
>wrote:
>> >
>> >> Can you please have a look and check regarding what should/could
>be
>> >> changed to get it upstream? We did not test the dynamic relocation
>part,
>> >
>> > Sure thing, please take a look below...
>> >
>> >> since we have no such (kernel) setup. Thanks in advance.
>> >
>> > You can use Xen (git://xenbits.xen.org/xen.git) for tests.
>> > Just compile hypervisor without any tools and use xen.gz.
>> > It produces nice output and you can see it is relocated or not.
>> > Of course you have to use Multiboot2 protocol.
>>
>> Thanks, I managed to setup it. Based on your comments and on the Xen
>> test case I had to re-work the patch, so that it now works for
>> relocation and non-relocation kernels.
>>
>> Please review again.
>> > However, this does not mean that I will not take this patch. Though
>> > it requires some tweaking.
>> >
>> > First of all, lack of SOB.
>>
>> What is a SOB ?
>
>Signed-off-by: Alexander Boettcher
>

There is more to it then that. Doing an SoB means you abide by the developer 
certificate.

See https://developercertificate.org/
>
>Next time please use git format-patch/send-email to send the patches.
>
>> From c37727840be8aeb81ea4bbc95ac09a1b1e3d3658 Mon Sep 17 00:00:00
>2001
>> From: Alexander Boettcher 
>> Date: Fri, 13 Apr 2018 23:37:01 +0200
>> Subject: [PATCH] mbi: use per segment a separate relocator chunk
>>
>> if elf is non relocatable.
>>
>> If the segments are not dense packed, the original code set up a huge
>> relocator chunk comprising all segments.
>>
>> During the final relocation in grub_relocator_prepare_relocs, the
>chunk
>> is moved to its desired place and overrides memory which are actually
>not
>> covered/touched by the specified segments.
>>
>> The overriden memory may contain device memory (vga text mode e.g.),
>which
>> leads to strange boot behaviour.
>
>Have you been able to take a look at memory allocator/relocator code
>why
>this happened?
>
>> ---
>>  grub-core/loader/multiboot_elfxx.c | 56
>--
>>  1 file changed, 35 insertions(+), 21 deletions(-)
>>
>> diff --git a/grub-core/loader/multiboot_elfxx.c
>b/grub-core/loader/multiboot_elfxx.c
>> index 67daf59..d936223 100644
>> --- a/grub-core/loader/multiboot_elfxx.c
>> +++ b/grub-core/loader/multiboot_elfxx.c
>> @@ -57,9 +57,9 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>>char *phdr_base;
>>grub_err_t err;
>>grub_relocator_chunk_t ch;
>> -  grub_uint32_t load_offset, load_size;
>> +  grub_uint32_t load_offset = 0, load_size;
>>int i;
>> -  void *source;
>> +  void *source = NULL;
>>
>>if (ehdr->e_ident[EI_MAG0] != ELFMAG0
>>|| ehdr->e_ident[EI_MAG1] != ELFMAG1
>> @@ -83,6 +83,7 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>>  #define phdr(i) ((Elf_Phdr *) (phdr_base + (i) *
>ehdr->e_phentsize))
>>
>>mld->link_base_addr = ~0;
>> +  mld->load_base_addr = ~0;
>>
>>/* Calculate lowest and highest load address.  */
>>for (i = 0; i < ehdr->e_phnum; i++)
>> @@ -108,27 +109,19 @@ CONCAT(grub_multiboot_load_elf, XX)
>(mbi_load_data_t *mld)
>>mld->min_addr, mld->max_addr - 
>> load_size,
>>load_size, mld->align ? 
>> mld->align : 1,
>>mld->preference, 
>> mld->avoid_efi_boot_services);
>> -}
>> -  else
>> -err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT
>(relocator), ,
>> -   mld->link_base_addr, load_size);
>>
>> -  if (err)
>> -{
>> -  grub_dprintf ("multiboot_loader", "Cannot allocate memory for
>OS image\n");
>> -  return err;
>> -}
>> +  if (err)
>> +{
>> +  grub_dprintf ("multiboot_loader", "Cannot allocate memory
>for OS image\n");
>> +  return err;
>> +}
>>
>> -  mld->load_base_addr = get_physical_target_address (ch);
>> -  source = get_virtual_current_address (ch);
>> +  mld->load_base_addr = get_physical_target_address (ch);
>> +  source = get_virtual_current_address (ch);
>>
>> -  grub_dprintf ("multiboot_loader", "link_base_addr=0x%x,
>load_base_addr=0x%x, "
>> -"load_size=0x%x, relocatable=%d\n", mld->link_base_addr,
>> -mld->load_base_addr, load_size, mld->relocatable);
>
>I would not drop it completely from ~here. I think that you can display
>link_base_addr and relocatable just before current line 102. And you
>can
>put "load_size = highest_load - mld->link_base_addr;" just before
>current
>line 104. Additionally, load_size does not have a 

Re: [Xen-devel] Xen PVH support in grub2

[Konrad Rzeszutek Wilk]

On Tue, Nov 07, 2017 at 11:10:29AM -0500, Boris Ostrovsky wrote:
> On 11/07/2017 02:42 AM, Juergen Gross wrote:
> > On 06/11/17 17:42, Boris Ostrovsky wrote:
> >> On 11/06/2017 10:05 AM, Juergen Gross wrote:
> >>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>  On 11/06/2017 02:16 AM, Juergen Gross wrote:
> > On 03/11/17 20:00, Boris Ostrovsky wrote:
> >> On 11/03/2017 02:40 PM, Juergen Gross wrote:
> >>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>  On 11/03/2017 02:23 PM, Juergen Gross wrote:
> > On 03/11/17 19:19, Boris Ostrovsky wrote:
> >> On 11/03/2017 02:05 PM, Juergen Gross wrote:
> >>> So again the question: how to tell whether we are PVH or HVM in
> >>> init_hypervisor_platform()? ACPi tables are scanned way later...
> >> Can we make grub/OVMF append a boot option?
> >>
> >> Or set setup_header.hardware_subarch to something? We already have
> >> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to 
> >> use
> >> hardware_subarch_data (will need to get a buy-in from x86 
> >> maintainers, I
> >> think).
> > But wouldn't this break the idea to reuse the native boot paths in
> > grub/OVMF without further modifications?
>  WDYM? We will have to have some sort of a plugin in either one to 
>  build
>  the zeropage anyway. So we'd set hardware_subarch there, in addition 
>  to
>  other things like setting memory and such.
> >>> But isn't the zeropage already being built? I admit that setting 
> >>> subarch
> >>> isn't a big deal, but using another entry with a passed-through pvh
> >>> start struct isn't either...
> >> I don't follow, sorry. My understanding is that zeropage will be built
> >> by PVH-enlightened grub so part of this process would be setting the
> >> subarch bit.
> > My reasoning was based on Roger's remark:
> >
> > "OTOH if Linux is capable of booting from the native entry point inside
> > of a PVH container, we would only have to port OVMF and grub in order
> > to work inside of a PVH container, leaving the rest of the logic
> > untouched."
>  Right, and in my mind porting OVMF/grub includes creating proper 
>  zeropage.
> >>> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
> >>> in PVH environment without touching the parts setting up anything for
> >>> the new kernel.
> >> Someone needs to do what xen_prepare_pvh() does.
> > As the loader is filling in the memory map information 
> 
> That's the thing that I thought may need to be done by us (setting
> commandline too) . But I haven't looked at Xen support in grub so maybe
> it's already there.
> 
> > the only thing
> > remaining would be setting xen_pvh. And this could be delayed as my test
> > have shown, so we only need to detect the PVH case from inside the
> > kernel. One possibility would be the flags in the ACPI FADT table as
> > Roger mentioned, another idea would be a flag in zeropage set by the
> > loader.
> >
> >> And, for 64-bit, we also may need to build early pagetables since
> >> startup_64() (unlike startup_32()) expects paging to be on. (I don't
> >> know whether this is already part of standard FW codepath)
> > This would be done the same way as for a native kernel.
> 
> This is done by Linux trampoline code. AFAIK grub loads kernel in realmode.

Adding in Maran who is looking at re-using PVH for qemu launching
the kernels.

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

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS boot environment patch

[Konrad Rzeszutek Wilk]

On Fri, Sep 15, 2017 at 12:57:39AM +0100, Colin Watson wrote:
> On Thu, Sep 14, 2017 at 09:22:01PM +0200, Paul Lagerweij wrote:
> > On Wed, 13 Sep 2017 at 09:17:42PM +0100, Colin Watson wrote:
> > > > On Wed, Sep 13, 2017 at 11:02:48AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > @@ -62,9 +63,15 @@ case x"$GRUB_FS" in
> > > > > +   zfs_active_bootfs="`zpool list -H -o bootfs ${rpool} || true`"
> > > >
> > > > Is zpool usually in /sbin or such? Perhaps a full path?
> > >
> > > Full paths are brittle when they refer to something installed by a
> > > different package.  If you need to do that kind of thing then it's
> > > usually better to temporarily extend $PATH instead.
> > 
> > Do you mean that grub-mkconfig has its own $PATH and that I should
> > temporarily change it to the user's $PATH? If so, can the 10_linux script
> > see the user's $PATH?
> 
> No, that's not what we mean.  Konrad's point is that /sbin (and
> /usr/sbin) may not be in $PATH when grub-mkconfig is invoked.  (I'm not
> sure I agree that this is likely because grub-mkconfig is normally
> invoked as root and root's $PATH normally includes /sbin, but Konrad
> seems to think it's a possibility worth worrying about.)
> 
> A reasonable solution to this kind of thing is to set
> PATH="$PATH:/sbin:/usr/sbin" to ensure that utilities there are
> available.

Which is much better than what I had mind. In other words, just
disregard my suggestion to add '/sbin' to the patch.
> 
> -- 
> Colin Watson   [cjwat...@ubuntu.com]
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB documentation updated

[Konrad Rzeszutek Wilk]

On Thu, Sep 07, 2017 at 09:12:33PM +0200, Daniel Kiper wrote:
> Hey,
> 
> Some people asked me about Multiboot2 Specification and other GRUB doc stuff.
> So, I have put latest things at
>   https://www.gnu.org/software/grub/grub-documentation.html

Yeey! Thank you for doing that!
> 
> I hope that helps. If you have any questions please drop me a line.
> 
> Thanks,
> 
> Daniel
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: ZFS boot environment patch

[Konrad Rzeszutek Wilk]

On Fri, Sep 01, 2017 at 01:31:28PM +0200, Paul Lagerweij wrote:
> Hello,
> 
> I've created a patch for util/grub.d/10_linux.in for dynamic ZFS boot
> environment entries. I've only tested the patch in Ubuntu 16.04.2 with GRUB
> 2.02~beta2, ZFS on Linux 0.6.5.6, Linux 4.4.0-83 and 4.4.0-81, but the
> patch should work with any root ZFS configuration, because it only changes
> the 10_linux shell script. It is designed to work with FreeBSD's beadm
> tool, for which I'm currently making a Debian package, but isn't dependent
> on beadm. I added the patch as an attachment and would like to request a
> review.

You seem to be missing an Signed off?

And perhaps an commit description?
> 
> Thanks.

> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
> index de9044c..c9a318e 100644
> --- a/util/grub.d/10_linux.in
> +++ b/util/grub.d/10_linux.in
> @@ -20,6 +20,7 @@ set -e
>  prefix="@prefix@"
>  exec_prefix="@exec_prefix@"
>  datarootdir="@datarootdir@"
> +zfs_be="0"

Why not just

zfs_be=

And then you can just check for zfs_be having an value instead of for 1 or 0?

Or alternatively,

zfs_be=0

and then you can do if [ $zfs_be -ne 0 ]; .. or such?

>  
>  . "$pkgdatadir/grub-mkconfig_lib"
>  
> @@ -62,9 +63,15 @@ case x"$GRUB_FS" in
>   fi;;
>  xzfs)
>   rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 
> 2>/dev/null || true`
> - bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
> - LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
> - ;;
> + zfs_active_bootfs="`zpool list -H -o bootfs ${rpool} || true`"

Is zpool usually in /sbin or such? Perhaps a full path?
> + if [ -n "${zfs_active_bootfs}" ] && [ "${zfs_active_bootfs}" != "-" ] 
> && \
> +[ `echo ${zfs_active_bootfs} | grep -o '/' | wc -l` -gt 1 ]; then
> + zfs_be="1"
> + LINUX_ROOT_DEVICE="ZFS=${zfs_active_bootfs}"
> + else
> + bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
> + LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs}"
> + fi;;

Did you test this where zpool is not installed?
>  esac
>  
>  title_correction_code=
> @@ -177,6 +184,16 @@ title_correction_code=
>  # yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
>  submenu_indentation=""
>  
> +if [ "${zfs_be}" = 1 ]; then
> +  while read ZFS_BE_NAME ZFS_ORIGIN; do
> +if [ "${ZFS_ORIGIN}" != "-" ]; then
> +  zfs_be_list="${zfs_be_list} ${ZFS_BE_NAME}"
> +fi
> +  done << EOF
> +`zfs list -H -t filesystem -S creation -o name,origin -d 1 
> ${zfs_active_bootfs%/*} || true`
> +EOF
> +fi
> +
>  is_top_level=true
>  while [ "x$list" != "x" ] ; do
>linux=`version_find_latest $list`
> @@ -184,6 +201,10 @@ while [ "x$list" != "x" ] ; do
>basename=`basename $linux`
>dirname=`dirname $linux`
>rel_dirname=`make_system_path_relative_to_its_root $dirname`
> +  # If ZFS BE support and /boot is in ZFS.
> +  if [ "${zfs_be}" = 1 ] && [ -n "${rel_dirname}" ]; then
> +rel_dirname="/""${zfs_active_bootfs#*/}""@/boot"
> +  fi
>version=`echo $basename | sed -e "s,^[^0-9]*-,,g"`
>alt_version=`echo $version | sed -e "s,\.old$,,g"`
>linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
> @@ -238,12 +259,53 @@ while [ "x$list" != "x" ] ; do
>  is_top_level=false
>fi
>  
> -  linux_entry "${OS}" "${version}" advanced \
> -  "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
> -  if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
> -linux_entry "${OS}" "${version}" recovery \
> -"single ${GRUB_CMDLINE_LINUX}"
> -  fi
> +  for menu_entries_group in default ${zfs_be_list}; do
> +found_entry="0"
> +if [ "${menu_entries_group}" = "default" ]; then
> +  found_entry="1"
> +  os_title="${OS}"
> +else
> +  found_zfs_be="0"
> +  zfs_be_name=${menu_entries_group}
> +  # If /boot is not in ZFS.
> +  if [ -z "${rel_dirname}" ]; then
> +found_zfs_be="1"
> +  else
> +zfs_be_mounted="`zfs list -H -o mounted ${zfs_be_name}`"
> +if [ "${zfs_be_mounted}" = "yes" ]; then
> +  ZFSMNT=`mount | grep -m 1 "^${zfs_be_name} " | cut -d' ' -f3)`
> +else
> +  ZFSMNT=`mktemp -d "/tmp/$(echo ${zfs_be_name} | sed 
> 's^/^-^g').XXX" || true`
> +  zfs set mountpoint=legacy ${zfs_be_name} || true
> +  mount -t zfs -o ro ${zfs_be_name} ${ZFSMNT} || true
> +fi
> +if [ -n "${ZFSMNT}" ] && [ -f "${ZFSMNT}/boot/vmlinuz-${version}" ]; 
> then
> +  found_zfs_be="1"
> +  rel_dirname="/""${zfs_be_name#*/}""@/boot"
> +fi
> +if [ "${zfs_be_mounted}" != "yes" ]; then
> +  umount ${ZFSMNT} && rm -rf ${ZFSMNT} || true
> +  zfs set mountpoint=/ ${zfs_be_name} || true
> +fi
> +  fi
> +
> +  if [ "${found_zfs_be}" = 1 ]; then
> +found_entry="1"
> +os_title="${OS} (${zfs_be_name##*/} BE)"
> +gettext_printf "Found ZFS boot environment: (%s 

Commits in origin/master that haven't been posted on grub-devel?

[Konrad Rzeszutek Wilk]

Hey,

As I was checking on 'origin/master' hoping to see two of my patches
checked in I noticed these:

commit 78d2b81bd1af0a3a84d0c23c9ff4af3caa2df23b (origin/master, origin/HEAD)
Author: Vladimir Serbinenko 
Date:   Thu Sep 7 13:55:22 2017 +0200

Fix compilation for x86_64-efi.

commit 1b18d6b0d34872ced6b3dbfc3e7957c80efbcb7a
Author: Vladimir Serbinenko 
Date:   Tue Sep 5 23:13:55 2017 +0200

Add a file missing in multiboot2 commit.

commit 95acd4cbdac495c088fc3401fa365455f7039151
Author: Vladimir Serbinenko 
Date:   Wed Aug 30 20:46:14 2017 +0200

gzio: fix unaligned access


Could you please start posting your patches on grub-devel as the
norm that happens on lkml, xen-devel, qemu-devel, libvirt-devel,
and probably most of the open source projects?

Thank you.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2] Fix ARM multiboot2 breaking Fedora.

[Konrad Rzeszutek Wilk]

Since v1 [http://lists.gnu.org/archive/html/grub-devel/2017-08/msg00073.html]
 - Fixed up patch with failing invocation,
 - Redid patch #2 per Daniel's instructions.


Hey,

The first patch:
 [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command

is a fix discovered on Fedora rawhide where I was surprised to see that
grub2-mkconfig would not create a configuration file anymore.

The second patch has been posted in the past
(https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt)

 [PATCH 2/2] Use grub-file to figure out whether multiboot2 should be

and just allows us to multiboot2 instead of multiboot if the binary
supports it.


 util/grub.d/20_linux_xen.in | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)


Konrad Rzeszutek Wilk (2):
  Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
  Use grub-file to figure out whether multiboot2 should be used for Xen.gz


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2 2/2] Use grub-file to figure out whether multiboot2 should be used for Xen.gz

[Konrad Rzeszutek Wilk]

The multiboot2 is much more preferable than multiboot. Especiall
if booting under EFI where multiboot does not have the functionality
to pass ImageHandler.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v2: Rebase on top of  d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe
v3: Add 'else' in the conditional.
Use a tab and four spaces instead of two tabs.
---
 util/grub.d/20_linux_xen.in | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 083bcef..0cb0f4e 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -210,8 +210,13 @@ while [ "x${xen_list}" != "x" ] ; do
xen_loader="xen_hypervisor"
module_loader="xen_module"
 else
-   xen_loader="multiboot"
-   module_loader="module"
+   if ($grub_file --is-x86-multiboot2 $current_xen); then
+   xen_loader="multiboot2"
+   module_loader="module2"
+   else
+   xen_loader="multiboot"
+   module_loader="module"
+fi
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

[Konrad Rzeszutek Wilk]

Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
the support for this, but it does not work under x86 (as it stops
20_linux_xen from running).

The 20_linux_xen is run under a shell and any exits from within it:

(For example on x86):
+ /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
[root@tst063 grub]# echo $?
1

will result in 20_linux_xen exiting without continuing
and also causing grub2-mkconfig to stop processing.

As in:

 [root@tst063 grub]# ./grub-mkconfig | tail
 Generating grub configuration file ...
 Found linux image: /boot/vmlinuz-4.13.0-0.rc5.git1.1.fc27.x86_64
 Found initrd image: /boot/initramfs-4.13.0-0.rc5.git1.1.fc27.x86_64.img
 Found linux image: /boot/vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2
 Found initrd image: 
/boot/initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
echo'Loading Linux 
0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 ...'
linux   /vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 
root=/dev/mapper/fedora_tst063-root ro single
echo'Loading initial ramdisk ...'
initrd  /initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
}
 }

 ### END /usr/local/etc/grub.d/10_linux ###

 ### BEGIN /usr/local/etc/grub.d/20_linux_xen ###

 root@tst063 grub]#

And no more.

This patch wraps the invocation of grub-file to be a in subshell
and to process the return value in a conditional. That fixes
the issue.

RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
CC: Fu Wei <fu@linaro.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v1: Initial patch
v2: Add the failing output.
---
 util/grub.d/20_linux_xen.in | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c002fc9..083bcef 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
 if [ "x$is_top_level" != xtrue ]; then
echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
"${xen_version}" | grub_quote)' \$menuentry_id_option 
'xen-hypervisor-$xen_version-$boot_device_id' {"
 fi
-$grub_file --is-arm64-efi $current_xen
-if [ $? -ne 0 ]; then
-   xen_loader="multiboot"
-   module_loader="module"
-else
+if ($grub_file --is-arm64-efi $current_xen); then
xen_loader="xen_hypervisor"
module_loader="xen_module"
+else
+   xen_loader="multiboot"
+   module_loader="module"
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

[Konrad Rzeszutek Wilk]

On Tue, Aug 29, 2017 at 03:12:59PM +0800, Fu Wei Fu wrote:
> Hi  Konrad,
> 
> Thanks for your feedback.

Thank you for speedy response!
> 
> On 29 August 2017 at 02:40, Konrad Rzeszutek Wilk
> <konrad.w...@oracle.com> wrote:
> > Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
> > the support for this, but it does not work under x86 (as it stops
> > 20_linux_xen from running).
> >
> > The 20_linux_xen is run under a shell and any exits from within it:
> >
> 
> For your example
> 
> > (For example on x86):
> > + /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
> > [root@tst063 grub]# echo $?
> > 1
> 
> I guess that is right behavior, then
>   xen_loader="multiboot"
>module_loader="module"
> 
>  /boot/xen-4.9.0.gz is a xen binary for x86, right?

Correct. I also tested it with an xen.efi which was built for ARM (I copied
it in /boot/ directroy), and it created an proper entry for it:

xen_hypervisor  /xen.efi placeholder dom0_max_vcpus=2 dom0_mem=max:2G 
loglvl=all guest_loglvl=all console=com1 com1=115200,8n1 iommu=verbose,debug 
scan=ucode conring_size=2097152  ${xen_rm_opts}

en_module  /vmlinuz-4.13.0-0.rc5.git1.1.fc27.x86_64 placeholder 
root=/dev/mapper/fedora_tst063-root ro rd.lvm.lv=fedora_tst063/root 
rd.lvm.lv=fedora_tst063/swap loglevel=8 console=hvc0

...

Naturally I didn't try to boot it as it would most surely not work.
> 
> >
> > will result in 20_linux_xen exciting without continuing
> > and also causing grub2-mkconfig to stop processing.
> 
> maybe we are using different shell?  are you using ash?


[root@tst063 fedora]# head -2 `which grub2-mkconfig` 
#! /bin/sh
set -e

And the upstream grub shows:

[root@tst063 grub]# head -2 ./util/grub-mkconfig.in
#! /bin/sh
set -e


I am assuming you are using ARM, in which case I would recommend you
just copy xen.gz (compiled for x86) in your /boot directory. You should
get a similar failure condition as I got.

> 
> >
> > As in:
> >
> > [root@tst063 ~]#
> >
> > And no more.
> >
> > This patch wraps the invocation of grub-file to be a in subshell
> > and to process the return value in a conditional. That fixes
> > the issue.
> >
> > RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
> > CC: Fu Wei <fu@linaro.org>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> > ---
> >  util/grub.d/20_linux_xen.in | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
> > index c002fc9..083bcef 100644
> > --- a/util/grub.d/20_linux_xen.in
> > +++ b/util/grub.d/20_linux_xen.in
> > @@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
> >  if [ "x$is_top_level" != xtrue ]; then
> > echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
> > "${xen_version}" | grub_quote)' \$menuentry_id_option 
> > 'xen-hypervisor-$xen_version-$boot_device_id' {"
> >  fi
> > -$grub_file --is-arm64-efi $current_xen
> > -if [ $? -ne 0 ]; then
> > -   xen_loader="multiboot"
> > -   module_loader="module"
> > -else
> > +if ($grub_file --is-arm64-efi $current_xen); then
> > xen_loader="xen_hypervisor"
> > module_loader="xen_module"
> > +else
> > +   xen_loader="multiboot"
> > +   module_loader="module"
> >  fi
> >  while [ "x$list" != "x" ] ; do
> > linux=`version_find_latest $list`
> > --
> > 2.1.4
> >
> 
> 
> 
> -- 
> Best regards,
> 
> Fu Wei
> Software Engineer
> Red Hat

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

[Konrad Rzeszutek Wilk]

On Mon, Aug 28, 2017 at 02:40:14PM -0400, Konrad Rzeszutek Wilk wrote:
> Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
> the support for this, but it does not work under x86 (as it stops
> 20_linux_xen from running).
> 
> The 20_linux_xen is run under a shell and any exits from within it:
> 
> (For example on x86):
> + /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
> [root@tst063 grub]# echo $?
> 1
> 
> will result in 20_linux_xen exciting without continuing
> and also causing grub2-mkconfig to stop processing.
> 
> As in:

git format-patch decided to eat this relevant part:

[root@tst063 grub]# ./grub-mkconfig | tail
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.0-0.rc5.git1.1.fc27.x86_64
Found initrd image: /boot/initramfs-4.13.0-0.rc5.git1.1.fc27.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2
Found initrd image: 
/boot/initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
echo'Loading Linux 
0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 ...'
linux   /vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 
root=/dev/mapper/fedora_tst063-root ro single 
echo'Loading initial ramdisk ...'
initrd  /initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
}
}

### END /usr/local/etc/grub.d/10_linux ###

### BEGIN /usr/local/etc/grub.d/20_linux_xen ###

root@tst063 grub]# 

> 
> [root@tst063 ~]#
> 
> And no more.
> 
> This patch wraps the invocation of grub-file to be a in subshell
> and to process the return value in a conditional. That fixes
> the issue.
> 
> RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
> CC: Fu Wei <fu@linaro.org>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> ---
>  util/grub.d/20_linux_xen.in | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
> index c002fc9..083bcef 100644
> --- a/util/grub.d/20_linux_xen.in
> +++ b/util/grub.d/20_linux_xen.in
> @@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
>  if [ "x$is_top_level" != xtrue ]; then
>   echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
> "${xen_version}" | grub_quote)' \$menuentry_id_option 
> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>  fi
> -$grub_file --is-arm64-efi $current_xen
> -if [ $? -ne 0 ]; then
> - xen_loader="multiboot"
> - module_loader="module"
> -else
> +if ($grub_file --is-arm64-efi $current_xen); then
>   xen_loader="xen_hypervisor"
>   module_loader="xen_module"
> +else
> + xen_loader="multiboot"
> + module_loader="module"
>  fi
>  while [ "x$list" != "x" ] ; do
>   linux=`version_find_latest $list`
> -- 
> 2.1.4
> 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH 2/2] Use grub-file to figure out whether multiboot2 should be used for Xen.gz

[Konrad Rzeszutek Wilk]

The multiboot2 is much more preferable than multiboot. Especiall
if booting under EFI where multiboot does not have the functionality
to pass ImageHandler.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
v2: Rebase on top of  d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe
---
 util/grub.d/20_linux_xen.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 083bcef..29e015b 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -212,6 +212,10 @@ while [ "x${xen_list}" != "x" ] ; do
 else
xen_loader="multiboot"
module_loader="module"
+   if ($grub_file --is-x86-multiboot2 $current_xen); then
+   xen_loader="multiboot2"
+   module_loader="module2"
+   fi
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Fix ARM multiboot2 breaking Fedora.

[Konrad Rzeszutek Wilk]

Hey,

The first patch:
 [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command

is a fix discovered on Fedora rawhide where I was surprised to see that
grub2-mkconfig would not create a configuration file anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1486002 for details.


The second patch has been posted in the past
(https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt)

 [PATCH 2/2] Use grub-file to figure out whether multiboot2 should be

and just allows us to multiboot2 instead of multiboot if the binary
supports it.


 util/grub.d/20_linux_xen.in | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

Konrad Rzeszutek Wilk (2):
  Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
  Use grub-file to figure out whether multiboot2 should be used for Xen.gz


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

[Konrad Rzeszutek Wilk]

Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
the support for this, but it does not work under x86 (as it stops
20_linux_xen from running).

The 20_linux_xen is run under a shell and any exits from within it:

(For example on x86):
+ /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
[root@tst063 grub]# echo $?
1

will result in 20_linux_xen exciting without continuing
and also causing grub2-mkconfig to stop processing.

As in:

[root@tst063 ~]#

And no more.

This patch wraps the invocation of grub-file to be a in subshell
and to process the return value in a conditional. That fixes
the issue.

RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
CC: Fu Wei <fu@linaro.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
 util/grub.d/20_linux_xen.in | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c002fc9..083bcef 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
 if [ "x$is_top_level" != xtrue ]; then
echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
"${xen_version}" | grub_quote)' \$menuentry_id_option 
'xen-hypervisor-$xen_version-$boot_device_id' {"
 fi
-$grub_file --is-arm64-efi $current_xen
-if [ $? -ne 0 ]; then
-   xen_loader="multiboot"
-   module_loader="module"
-else
+if ($grub_file --is-arm64-efi $current_xen); then
xen_loader="xen_hypervisor"
module_loader="xen_module"
+else
+   xen_loader="multiboot"
+   module_loader="module"
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 14/14] efi: change heap allocation type to GRUB_EFI_LOADER_CODE

[Konrad Rzeszutek Wilk]

On Mon, Aug 07, 2017 at 02:11:16PM +, Vladimir 'phcoder' Serbinenko wrote:
> LGTM

Is LGTM equivalant to Acked-by?

> 
> Le Thu, Aug 3, 2017 à 12:09 PM, Leif Lindholm  a
> écrit :
> 
> > With upcoming changes to EDK2, allocations of type EFI_LOADER_DATA may
> > not return regions with execute ability. Since modules are loaded onto
> > the heap, change the heap allocation type to GRUB_EFI_LOADER_CODE in
> > order to permit execution on systems with this feature enabled.
> >
> > Closes: 50420
> >
> > Signed-off-by: Leif Lindholm 
> > ---
> >  grub-core/kern/efi/mm.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
> > index c8fffe902..f1424f2e4 100644
> > --- a/grub-core/kern/efi/mm.c
> > +++ b/grub-core/kern/efi/mm.c
> > @@ -448,7 +448,9 @@ add_memory_regions (grub_efi_memory_descriptor_t
> > *memory_map,
> >   pages = required_pages;
> > }
> >
> > -  addr = grub_efi_allocate_pages (start, pages);
> > +  addr = grub_efi_allocate_pages_real (start, pages,
> > +  GRUB_EFI_ALLOCATE_ADDRESS,
> > +  GRUB_EFI_LOADER_CODE);
> >if (! addr)
> > grub_fatal ("cannot allocate conventional memory %p with %u pages",
> > (void *) ((grub_addr_t) start),
> > --
> > 2.11.0
> >
> >
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >

> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] multiboot2: Fix alignment of header tags

[Konrad Rzeszutek Wilk]

On Fri, Mar 10, 2017 at 05:13:58PM +0100, Daniel Kiper wrote:
> Header tags have to be 8-bytes aligned. So, fix it.
> Additionally, mention header closing tag in the spec.
> 
> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>

> ---
>  doc/multiboot.texi |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index a9c3f16..2e2d7e7 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -408,8 +408,9 @@ and @samp{header_length}), must have a 32-bit unsigned 
> sum of zero.
>  
>  @node Header tags
>  @subsection General tag structure
> -Tags constitutes a buffer of structures following each other padded on 
> @samp{u32} size.
> -Every structure has following format:
> +Tags constitutes a buffer of structures following each other padded when 
> necessary
> +in order for each tag to start at 8-bytes aligned address. Tags are 
> terminated by
> +a tag of type @samp{0} and size @samp{8}. Every structure has following 
> format:
>  
>  @example
>  @group
> -- 
> 1.7.10.4
> 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add fwconfig command

[Konrad Rzeszutek Wilk]

On Tue, Jan 24, 2017 at 04:36:03PM +, Colin Watson wrote:
> On Tue, Jan 24, 2017 at 09:52:35AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 23, 2017 at 03:43:32PM -0800, Matthew Garrett wrote:
> > > + *  GRUB is free software: you can redistribute it and/or modify
> > > + *  it under the terms of the GNU General Public License as published by
> > > + *  the Free Software Foundation, either version 3 of the License, or
> > > + *  (at your option) any later version.
> > 
> > So what is your option here (see the 'at your option'). 
> 
> This language indicates that it's at the option of the person
> redistributing or modifying it whether they do so under the terms of
> version 3 or of some later version.  Matthew is not required to pick
> one.

I mean I am reading this and it sounds like that
too but then this is an legal aggreement and those seem to
operate on some weird rules.

Does FSF have an unqualified answer to this?

> 
> Also:
> 
>   <cjwatson@niejwein ~/src/gnu/grub2/git/grub (master=)>$ git grep 'at your 
> option' | wc -l
>   1412

Which could mean that nobody reads that stuff and just copies
and pastes.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add fwconfig command

[Konrad Rzeszutek Wilk]

On Mon, Jan 23, 2017 at 03:43:32PM -0800, Matthew Garrett wrote:
> Add a command to read values from the qemu fwcfg store. This allows data
> to be passed from the qemu command line to grub.
> 
> Example use:
> 
> echo '(hd0,1)' >rootdev
> qemu -fw_cfg opt/rootdev,file=rootdev
> 
> fwconfig opt/rootdev root
> ---
>  docs/grub.texi|   6 +++
>  grub-core/Makefile.core.def   |   6 +++
>  grub-core/commands/fwconfig.c | 121 
> ++
>  3 files changed, 133 insertions(+)
>  create mode 100644 grub-core/commands/fwconfig.c
> 
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 4469638..4f8a378 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3818,6 +3818,7 @@ you forget a command, you can run the command 
> @command{help}
>  * eval::Evaluate agruments as GRUB commands
>  * export::  Export an environment variable
>  * false::   Do nothing, unsuccessfully
> +* fwconfig::Retrieves a value from the qemu fwcfg store
>  * getenv::  Retrieve an EFI firmware variable
>  * gettext:: Translate a string
>  * gptsync:: Fill an MBR based on GPT entries
> @@ -4259,6 +4260,11 @@ Do nothing, unsuccessfully.  This is mainly useful in 
> control constructs
>  such as @code{if} and @code{while} (@pxref{Shell-like scripting}).
>  @end deffn
>  
> +@node fwconfig
> +@subsection fwconig
> +@deffn Command fwconfig fwpath envvar
> +Retrieves @var{fwpath} from the qemu fwcfg store and stores it in 
> @var{envvar}
> +
>  @node getenv
>  @subsection getenv
>  
> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index db77a7f..f6b6f38 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -2362,3 +2362,9 @@ module = {
>common = loader/i386/xen_file64.c;
>extra_dist = loader/i386/xen_fileXX.c;
>  };
> +
> +module = {
> +  name = fwconfig;
> +  common = commands/fwconfig.c;
> +  enable = x86;
> +};
> diff --git a/grub-core/commands/fwconfig.c b/grub-core/commands/fwconfig.c
> new file mode 100644
> index 000..289d167
> --- /dev/null
> +++ b/grub-core/commands/fwconfig.c
> @@ -0,0 +1,121 @@
> +/* fwconfig.c - command to read config from qemu fwconfig  */
> +/*
> + *  GRUB  --  GRand Unified Bootloader
> + *  Copyright (C) 2015  CoreOS, Inc.


Hmm, 

See https://www.gnu.org/licenses/why-assign.html


> + *
> + *  GRUB is free software: you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation, either version 3 of the License, or
> + *  (at your option) any later version.

So what is your option here (see the 'at your option'). 

> + *
> + *  GRUB is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with GRUB.  If not, see .
> + */

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [MULTIBOOT2 DOC PATCH v3 07/13] multiboot2: Add description of support for EFI boot services

[Konrad Rzeszutek Wilk]

.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?

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Konrad Rzeszutek Wilk]

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 <daniel.ki...@oracle.com> 
> > 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 <konrad.w...@oracle.com>

Thank you for documenting this!
> 
> Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Patch: Improve HTTP time by sending Connection:close

[Konrad Rzeszutek Wilk]

On Thu, Nov 17, 2016 at 07:32:16PM +0100, Daniel Kiper wrote:
> On Tue, Nov 15, 2016 at 01:43:16PM -0800, Walter Huf wrote:
> > GRUB has a bug where it waits a minimum of 400ms for every file it fetches
> > over HTTP, unless the server serves it with Transfer-Encoding:chunked or
> > the file just happens to be split into 20 TCP packets. When using
> > pxeboot.img built with just pxe and http module (following instructions
> > from https://www.gnu.org/software/grub/manual/html_node/Network.html), this
> > causes an initial text menu to take about 7 seconds to load with all the
> > modules being dynamically fetched.
> 
> I agree that this looks like a bug.
> 
> > The SOB (statement of benefit?) of this patch is to fix this bug with the
> > smallest change to existing data structures and logic.
> 
> I meant Signed-off-by: ...
> In your case it should look like:
> 
> Signed-off-by: Walter Huf 

It is not as simple as that. Putting your SoB means that you:

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

then you just add a line saying

Signed-off-by: Random J Developer 


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: New maintainers

[Konrad Rzeszutek Wilk]

On Tue, Aug 16, 2016 at 03:32:12PM +, Vladimir 'phcoder' Serbinenko wrote:
> Hello, all. I’m delighted to announce that Daniel Kiper, Alexander
> Burmashev and Alexei Borzenkov have accepted to become co-maintainers of
> GNU GRUB.
> This is great news. In last 2 years my availability was limited and GRUB
> has suffered a lot from this. I tried to find skillful volunteers to help
> with the situation but unfortunately this was a very difficult task. Now
> that it’s done I ask you all to give them a warm welcome in this difficult
> task and all the support.
> I’ll be around to help with maintaining and will stay co-maintainer for
> near future. If you have think you need me personally for anything feel
> free to CC me directly. I’ll also be communicating with Daniel, Alex and
> Alex behind the scenes extensively.
> 
> Warm welcome and thank Alex, Alex and Daniel for taking on on this
> difficult task

Woohooo

Congratulations!

> Vladimir

> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v4 0/4] arm64,xen: add xen_boot support into grup-mkconfig

[Konrad Rzeszutek Wilk]

On Tue, May 10, 2016 at 10:03:22PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
> 
> This patchset add xen_boot support into grup-mkconfig for
> generating xen boot entrances automatically
> 

All of them look good to me.

Thanks!
> Also update the docs/grub.texi for new xen_boot commands.
> 
> This patchset has been tested on Foudation model with a bug fix:
> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html
> 
> ChangeLog:
> v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/
> according to the XSM loading mechanism of Xen(upstreamed),
> update the introduction of xen_module commands in docs/grub.texi
> 
> v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html
> reorder the patches
> update the introduction of xen_module commands in docs/grub.texi
> 
> v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html
> add "--nounzip" option support in xen_module
> use "feature_xen_boot" instead of "grub_xen_boot"
> update the introduction of xen boot commands in docs/grub.texi
> 
> v1 :first upstream patchset:
> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html
> 
> Fu Wei (4):
>   i386,xen: Add xen_hypervisor and xen_module aliases for i386
>   arm64: add "--nounzip" option support in xen_module command
>   * util/grub.d/20_linux_xen.in: Add xen_boot command support
>   arm64: update the introduction of xen boot commands in docs/grub.texi
> 
>  docs/grub.texi| 33 ++---
>  grub-core/loader/arm64/xen_boot.c | 17 +
>  grub-core/loader/i386/xen.c   |  7 +++
>  grub-core/normal/main.c   |  2 +-
>  util/grub.d/20_linux_xen.in   | 13 ++---
>  5 files changed, 45 insertions(+), 27 deletions(-)
> 
> -- 
> 2.5.5
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Bugs and tasks for 2.02[~rc1]

[Konrad Rzeszutek Wilk]

On Mon, Mar 28, 2016 at 10:59:03AM -0400, Konrad Rzeszutek Wilk wrote:
> ..snip..
> > What about
> > 
> > - disk IO buffer alignment for small read (I personally prefer the first
> > version of Leif's patch that exposes alignment in core, it also allows
> > us to print it in ls output)
> > 
> > - F2FS support
> > 
> > - SMBIOS patches
> > 
> > - getroot: Correctly handle missing btrfs device identifiers.​
> > 
> > - arm64,xen: add xen_boot support into grup-mkconfig
> 
> So .. what is involved in this? Xen is in its feature freeze window so I am 
> not
> exactly sure if the corresponding Xen patches have been posted?
> 
> Who is the author of these? (Not seeing it on the CC-list).

And I believe the underlaying Xen pieces are in? (On Xen side it is
"xen/arm64: check XSM Magic from the second unknown module." I believe).

> > 
> > - [RFC] Add exitcode support​ (or, better, suggestion in this thread to
> > change default exit code on EFI)
> > 
> > - something also needs to be done about
> > [PATCH] broken ESC navigation if authentication is used​
> 
> I would also add the multiboot2 from Daniel. I recall even seeing an email
> from Vladimir saying 'One more day and I will commit them' but I don't see
> them in the git tree?

ping? They have been reviewed..

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 06:00:27PM +0100, Daniel Kiper wrote:
> Currently multiboot2 protocol loads image exactly at address specified in
> ELF or multiboot2 header. This solution works quite well on legacy BIOS
> platforms. It is possible because memory regions are placed at predictable
> addresses (though I was not able to find any spec which says that it is
> strong requirement, so, it looks that it is just a goodwill of hardware
> designers). However, EFI platforms are more volatile. Even if required
> memory regions live at specific addresses then they are sometimes simply
> not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> OVMF). This means that you are not able to just set up final image
> destination on build time. You have to provide method to relocate image
> contents to real load address which is usually different than load address
> specified in ELF and multiboot2 headers.
> 
> This patch provides all needed machinery to do self relocation in image code.
> First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load addr),
> align (required image alignment), preference (it says which memory regions are
> preferred by image, e.g. none, low, high) from 
> multiboot_header_tag_relocatable
> header tag contained in binary (at this stage load addresses from multiboot2
> and/or ELF headers are ignored). Later loader tries to fulfill request (not 
> only
> that one) and if it succeeds then it informs image about real load address via
> multiboot_tag_load_base_addr tag. At this stage GRUB2 role is finished. 
> Starting
> from now executable must cope with relocations itself using whole static and
> dynamic knowledge provided by boot loader.
> 
> This patch does not provide functionality which could do relocations using
> ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and 
> Vladimir
> 'phcoder' Serbinenko to investigate that thing. It looks that relevant 
> machinery
> could be added to existing code (including this patch) without huge effort.
> Additionally, ELF relocation could live in parallel with self relocation 
> provided
> by this patch. However, during research I realized that first of all we should
> establish the details how ELF relocatable image should look like and how it 
> should
> be build. At least to build proper test/example files.
> 
> So, this patch just provides support for self relocatable images. If ELF file
> with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
> such files will be added later.
> 
> This patch was tested with Xen image which uses that functionality. However, 
> this Xen
> feature is still under development and new patchset will be released in about 
> 3-4 weeks.

> index e3a39b6..8a9ab0c 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c

..snip..
>  static grub_err_t
> -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, 
> void *buffer)
> +CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
>  {
> +#ifdef MULTIBOOT_LOAD_ELF64
> +  if (highest_load >= 0x1)
> +return grub_error (GRUB_ERR_BAD_OS, "segment cross 4 GiB border");

segment crosses 4GiB border!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Konrad Rzeszutek Wilk]

On Fri, Mar 18, 2016 at 06:00:23PM +0100, Daniel Kiper wrote:
> Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS. Relocator
> will set lower parts of %rax and %rbx accordingly to multiboot2 specification.
> On the other hand processor mode, just before jumping into loaded image, will
> be set accordingly to Unified Extensible Firmware Interface Specification,
> Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> loaded image will be able to use EFI boot services without any issues.
> 
> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>

.. with one modification:
.. snip..
> diff --git a/grub-core/lib/x86_64/efi/relocator.c 
> b/grub-core/lib/x86_64/efi/relocator.c
> new file mode 100644
> index 000..c93d061
> --- /dev/null
> +++ b/grub-core/lib/x86_64/efi/relocator.c
> +grub_err_t
> +grub_relocator64_efi_boot (struct grub_relocator *rel,
> +struct grub_relocator64_efi_state state)
> +{
> +  grub_err_t err;
> +  void *relst;
> +  grub_relocator_chunk_t ch;
> +
> +  err = grub_relocator_alloc_chunk_align (rel, , 0,
> +   0x4000 - RELOCATOR_SIZEOF 
> (64_efi),
  ^^ - why the 1GB?

Could you give a bit details on it? Or preferrable have a comment right
above saying what that value is used?

Thanks.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Konrad Rzeszutek Wilk]

On Wed, Mar 16, 2016 at 11:39:55AM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 16, 2016, Toomas Soome <tso...@me.com> wrote:
> 
> >
> > > On 16. märts 2016, at 12:02, Daniel Kiper <daniel.ki...@oracle.com
> > <javascript:;>> wrote:
> > >
> > > On Tue, Mar 15, 2016 at 07:46:46PM -0400, Konrad Rzeszutek Wilk wrote:
> > >> On Tue, Mar 15, 2016 at 04:26:00PM +0100, Daniel Kiper wrote:
> > >>> Do not pass memory maps to image if it asked for EFI boot services.
> > >>
> > >> .. I would change this sentence a bit.
> > >>
> > >> If image requested EFI boot services then skip multiboot2 memory maps.
> > >>
> > >>> Main reason for not providing maps is because they will likely be
> > >>> invalid. We do a few allocations after filling them, e.g. for relocator
> > >>> needs. Usually we do not care as we would already finish boot services.
> > >>
> > >> s/would already finish/would have finished/ ?
> > >>
> > >>> If we keep boot services then it is easier to not provide maps.
> > However,
> > >>
> > >> s/easier/safer?/
> > >>
> > >>> if image needs memory maps and they are not provided by bootloader then
> > >>> it should get them itself just before ExitBootServices() call.
> > >>
> > >> s/them// ?
> > >>
> > >> That is making an assumption that the user of Multiboot2 + EFI will
> > >> do this. Which is OK since only Xen is using it.. but is this
> > >> inline with the spec? Can you ignore not providing this information?
> > >
> > > AIUI, spec does not require that anything must be provided. Of course
> > > on every platform GRUB2 should provide minimal set of system information
> > > to properly boot loaded image. However, docs does not say which set make
> > > sense or not. This is role of image to know what it requires to properly
> > > run on a given platform. And I think that it make sense.
> > >
> > >> That aside - why not sync the multiboot memory map with what
> > >> the EFI one will be? Or is it too to complex to move the memory map
> > >> creation to a later phase of the bootup?
> > >
> > > IIRC, GRUB2 does some allocations after getting memory map and it is
> > > quite complicated to change that.
> > >
> > >> Wish there was some multboot memory map flag indicating
> > 'STALE-CHECK-EFI'..
> > >
> > > Why provide map which is invalid and must be verified with something
> > else?
> > > Let's ignore (do not provide) invalid data and use correct one without
> > > any additional (unneeded) checks.
> > >
> >
> > If you are *not* calling exit efi boot services from grub, there is no
> > sense to provide EFI memory map at all, because to exit boot services [from
> > OS], you *have to* fetch current memory map to get the map key to exit boot
> > services.
> >
> But this doesn't apply for e820-like and simple maps which are unaffected
> by bootloader allocations

Right. I think we are all on the same page then.

If EFI and payload (OS) has requested to be the one executing ExitBootServices
then don't provide the memory map?

But if the payload hasn't specified what to do with ExitBootServices, GRUB
is free to do so and provide the map.

> 
> >
> > basically it means, if BS is not disabled and grub is still providing EFI
> > memory map, the OS has to assume this map is not valid - which is bad and
> > better not to provide (potentially) invalid data in first place.

Right.

And the description of the patch (to my reading) was not exactly clear on this.

Perhaps just updating the description of the patch and repositing as reply
here would suffice?
> >
> > rgds,
> > toomas
> 
> 
> 
> -- 
> Regards
> Vladimir 'phcoder' Serbinenko

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Konrad Rzeszutek Wilk]

On Tue, Mar 15, 2016 at 04:26:00PM +0100, Daniel Kiper wrote:
> Do not pass memory maps to image if it asked for EFI boot services.

.. I would change this sentence a bit.

If image requested EFI boot services then skip multiboot2 memory maps.

> Main reason for not providing maps is because they will likely be
> invalid. We do a few allocations after filling them, e.g. for relocator
> needs. Usually we do not care as we would already finish boot services.

s/would already finish/would have finished/ ?

> If we keep boot services then it is easier to not provide maps. However,

s/easier/safer?/

> if image needs memory maps and they are not provided by bootloader then
> it should get them itself just before ExitBootServices() call.

s/them// ?

That is making an assumption that the user of Multiboot2 + EFI will
do this. Which is OK since only Xen is using it.. but is this
inline with the spec? Can you ignore not providing this information?


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

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


> 
> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> ---
> v3 - suggestions/fixes:
>- improve commit message
>  (suggested by Konrad Rzeszutek Wilk and Vladimir 'phcoder' Serbinenko).
> ---
>  grub-core/loader/multiboot_mbi2.c |   17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/grub-core/loader/multiboot_mbi2.c 
> b/grub-core/loader/multiboot_mbi2.c
> index 6c04402..ad1553b 100644
> --- a/grub-core/loader/multiboot_mbi2.c
> +++ b/grub-core/loader/multiboot_mbi2.c
> @@ -390,7 +390,7 @@ static grub_size_t
>  grub_multiboot_get_mbi_size (void)
>  {
>  #ifdef GRUB_MACHINE_EFI
> -  if (!efi_mmap_size)
> +  if (!keep_bs && !efi_mmap_size)
>  find_efi_mmap_size ();
>  #endif
>return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
> @@ -755,6 +755,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
>}
>}
>  
> +  if (!keep_bs)
>  {
>struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
>grub_fill_multiboot_mmap (tag);
> @@ -776,6 +777,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
>/ sizeof (grub_properly_aligned_t);
>}
>  
> +  if (!keep_bs)
>  {
>struct multiboot_tag_basic_meminfo *tag
>   = (struct multiboot_tag_basic_meminfo *) ptrorig;
> @@ -886,21 +888,17 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
>  grub_efi_uintn_t efi_desc_size;
>  grub_efi_uint32_t efi_desc_version;
>  
> +if (!keep_bs)
> +  {
>   tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
>   tag->size = sizeof (*tag) + efi_mmap_size;
>  
> -if (!keep_bs)
>   err = grub_efi_finish_boot_services (_mmap_size, tag->efi_mmap, 
> NULL,
>_desc_size, _desc_version);
> -else
> -  {
> - if (grub_efi_get_memory_map (_mmap_size, (void *) tag->efi_mmap,
> -  NULL,
> -  _desc_size, _desc_version) <= 0)
> -   err = grub_error (GRUB_ERR_IO, "couldn't retrieve memory map");
> -  }
> +
>   if (err)
> return err;
> +
>   tag->descr_size = efi_desc_size;
>   tag->descr_vers = efi_desc_version;
>   tag->size = sizeof (*tag) + efi_mmap_size;
> @@ -908,6 +906,7 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
>   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> / sizeof (grub_properly_aligned_t);
>}
> +  }
>  
>if (keep_bs)
>  {
> -- 
> 1.7.10.4
> 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [GRUB2 PATCH v4 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Konrad Rzeszutek Wilk]

On Tue, Mar 15, 2016 at 04:25:59PM +0100, Daniel Kiper wrote:
> Add tags used to pass ImageHandle to loaded image if requested.
> It is used by at least ExitBootServices() function.
> 
> Signed-off-by: Daniel Kiper <daniel.ki...@oracle.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> ---
> v4 - suggestions/fixes:
>- reduce number of #ifdefs in grub_multiboot_get_mbi_size()
>  (suggested by Vladimir 'phcoder' Serbinenko).
> 
> v3 - suggestions/fixes:
>- mbi EFI related stuff size calculation
>  should depend on target architecture
>  (suggested by Konrad Rzeszutek Wilk),
>- use plain type instead of pointer
>      dereference as sizeof() argument
>  (suggested by Konrad Rzeszutek Wilk),
>    - improve commit message
>  (suggested by Konrad Rzeszutek Wilk).
> ---
>  grub-core/loader/multiboot_mbi2.c |   42 
> ++---
>  include/multiboot2.h  |   16 ++
>  2 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/grub-core/loader/multiboot_mbi2.c 
> b/grub-core/loader/multiboot_mbi2.c
> index a3dca90..6c04402 100644
> --- a/grub-core/loader/multiboot_mbi2.c
> +++ b/grub-core/loader/multiboot_mbi2.c
> @@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char 
> *filename)
> case MULTIBOOT_TAG_TYPE_NETWORK:
> case MULTIBOOT_TAG_TYPE_EFI_MMAP:
> case MULTIBOOT_TAG_TYPE_EFI_BS:
> +   case MULTIBOOT_TAG_TYPE_EFI32_IH:
> +   case MULTIBOOT_TAG_TYPE_EFI64_IH:
>   break;
>  
> default:
> @@ -407,13 +409,15 @@ grub_multiboot_get_mbi_size (void)
>+ grub_get_multiboot_mmap_count ()
>* sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
>  + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), 
> MULTIBOOT_TAG_ALIGN)
> -+ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
> -+ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
>  + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
>   + sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
>  + acpiv2_size ()
>  + net_size ()
>  #ifdef GRUB_MACHINE_EFI
> ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
> ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
> ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
> ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
>  + ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
>   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
>  #endif
> @@ -907,11 +911,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
>  
>if (keep_bs)
>  {
> -  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> -  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> -  tag->size = sizeof (struct multiboot_tag);
> -  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> - / sizeof (grub_properly_aligned_t);
> +  {
> + struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> + tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> + tag->size = sizeof (struct multiboot_tag);
> + ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> +   / sizeof (grub_properly_aligned_t);
> +  }
> +
> +#ifdef __i386__
> +  {
> + struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
> ptrorig;
> + tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
> + tag->size = sizeof (struct multiboot_tag_efi32_ih);
> + tag->pointer = (grub_addr_t) grub_efi_image_handle;
> + ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> +   / sizeof (grub_properly_aligned_t);
> +  }
> +#endif
> +
> +#ifdef __x86_64__
> +  {
> + struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
> ptrorig;
> + tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
> + tag->size = sizeof (struct multiboot_tag_efi64_ih);
> + tag->pointer = (grub_addr_t) grub_efi_image_handle;
> + ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> +   / sizeof (grub_properly_aligned_t);
> +  }
> +#endif
>  }
>  #endif
>  
> diff --git a/include/multiboot2.h b/include/multiboot2.h
> index 46e7b71..f5bebe1 100644
> --- a/include/multiboot2.h
> +++ b/include/multiboot2.h
> @@ -60,6 +60,8 @@
>  #define MULTIBOOT_TAG_TYPE_NETWORK   16
>  #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
>  #define MULTIBOOT_TAG_TYPE_EFI_BS18
> +#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
> +#define M

Re: 2.02~beta3 release

[Konrad Rzeszutek Wilk]

On Sun, Feb 28, 2016 at 03:21:44PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> Hello, all. I've just released 2.02~beta3. The goal of this release is
> to chase bugs so that we can move to 2.02 release. So from now on if you
> think that your patch should be included in 2.02 rather than in 2.03,
> please add [2.02] to the beginning of your email subject

Woohoo!!! Thank you!

> 
> The tarball is available at
> http://alpha.gnu.org/gnu/grub/grub-2.02~beta3.tar.xz
> and signature at
> http://alpha.gnu.org/gnu/grub/grub-2.02~beta3.tar.xz.sig
> 
> Signed with following fingerprint:
>  E53D 497F 3FA4 2AD8 C9B4  D1E8 35A9 3B74 E82E 4209
> 
> It's also available as a signed tag grub-2.02-beta3 in official git
> repository.
> 
> If you don't have xz support alternatively you may consider files
> http://alpha.gnu.org/gnu/grub/grub-2.02~beta3.tar.xz
> and signature at
> http://alpha.gnu.org/gnu/grub/grub-2.02~beta3.tar.xz.sig
> 
> 
> 
> 



> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: FOSDEM

[Konrad Rzeszutek Wilk]

On January 31, 2016 4:12:15 AM EST, Vladimir 'phcoder' Serbinenko 
 wrote:
>If anybody would like to connect or discuss patches, design and so on,
>feel
>free to drop by at coreboot booth at FOSDEM. Non-coreboot GRUB topics
>are
>welcome as well

Thank you.

Could you in the future give more than 0 day notice please?

In lieu of face to face at FOSDEM would it be possible to setup Google Hangout 
meeting next week?

Thanks!

>
>
>
>
>___
>Grub-devel mailing list
>Grub-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/grub-devel



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH grub-core/kern/xen/init.c] pvgrub2 xen cmdline xenstore var to grubenv

[Konrad Rzeszutek Wilk]

On Fri, Oct 23, 2015 at 05:11:33PM -0700, Mark Pryor wrote:
> When entering the grub2 shell during a pvgrub2 boot, there is no info about 
> the current
> domU in the grubenv (set). Starting with a patch submitted by Olaf Herring I 
> exported

Which patch? Is there a name for it so it can be part of the
git commit history?

Thanks.
> the xenstore cmdline only.
> 
> The env var, xen_cmdline, can then be used in the top level script used to 
> make
> the pvgrub2 kernel blob.
> 
> Signed-off-by: Mark Pryor 
> ---
>  grub-core/kern/xen/init.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
> index 0559c03..2a3112d 100644
> --- a/grub-core/kern/xen/init.c
> +++ b/grub-core/kern/xen/init.c
> @@ -524,6 +524,29 @@ map_all_pages (void)
>grub_mm_init_region ((void *) heap_start, heap_end - heap_start);
>  }
>  
> +/*
> + * Find all name=val pairs in the provided cmd_line and export them
> + * so that scripts can evaluate the variables for their own purpose.
> + */
> +static void
> +export_cmdline (void)
> +{
> +  char *p;
> +  const char *name="xen_cmdline";
> +
> +  p = grub_malloc (MAX_GUEST_CMDLINE + 1);
> +  if (!p)
> +return;
> +
> +  grub_memcpy (p, grub_xen_start_page_addr->cmd_line, MAX_GUEST_CMDLINE);
> +  p[MAX_GUEST_CMDLINE] = '\0';
> +
> +  grub_env_set (name, p);
> +  grub_env_export (name);
> +
> +   grub_free (p);
> +}
> +
>  extern char _end[];
>  
>  void
> @@ -539,6 +562,8 @@ grub_machine_init (void)
>  
>map_all_pages ();
>  
> +  export_cmdline ();
> +
>grub_console_init ();
>  
>grub_tsc_init ();
> -- 
> 2.1.4
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GNU GRUB maintenance

[Konrad Rzeszutek Wilk]

On October 9, 2015 8:14:39 AM EDT, "Vladimir 'φ-coder/phcoder' Serbinenko" 
<phco...@gmail.com> wrote:
>On 08.10.2015 21:34, Konrad Rzeszutek Wilk wrote:
>> On October 8, 2015 10:52:25 AM EDT, Andrei Borzenkov
><arvidj...@gmail.com> wrote:
>>> On Thu, Oct 8, 2015 at 12:14 AM, Vladimir 'φ-coder/phcoder'
>Serbinenko
>>> <phco...@gmail.com> wrote:
>>>> Hello, all. I'm sorry for not being available to do enough
>>> maintenance
>>>> for GRUB in last time but I was overbooked. Yet there is a good
>news.
>>> At
>>>> Google there is a 20% project and GRUB has been approved as 20%
>>> project
>>>> for me. The goal is to have 2.02 released before the end of this
>>> year.
>>>> Other than the raw lack of time there is another issue which makes
>>>> maintenance difficult: inefficient VCS.
>>>
>>> VCS is actually OK. The project of size Linux kernel seems to work
>>> well using pull request e-mails. The disadvantages are
>>>
>>> - contributors must have repository available via Internet
>> 
>> 
>> That is quite easy nowadays. And you can always ask for signed tags
>if you are worried about repos being subverted.
>> 
>>> - contributors are trusted to actually submit pull request for
>branch
>>> that was reviewed
>> 
>> 
>> 
>> 
>> It is a disadvantage to trust people!?
>> 
>> 
>>> - it needs to be done locally and pushed
>> 
>> 
>> Or you can have different maintainers pushing the patches in if they
>are Acked or Reviewed.
>> 
>> Meaning the committee does not have to be the same person who
>reviews/acks it.
>> 
>>>
>>>>   It requires
>me
>>> or someone with
>>>> privileges manually copy the patch. What other systems would be ok?
>>> It
>>>> obviously has to be a free software and hosted on free
>>> software-friendly
>>>> hosting. It also has to have an efficient 1-click merge (so that
>>> someone
>>>> with privileges can get any patch submitted to the system merged in
>>>> couple of clicks).
>>>>
>>>>
>> 
>> Clicks? That sounds like a GUI thing. And it sounds like you need to
>have an admin to set it up, patch it occasionally, deal with spammers,
>etc.
>> 
>> What is wrong with the old mechanism of emails.
>> 
>It takes too much effort to:
>a) Track if there are any unresolved issues

Isn't that the job of the folks submitting the patches?

>b) It takes non-trivial amount of effort to commit once it's reviewed:
>you need to copy patch from mail client to git, do commit, copy
>description and so on

Huh? 'git am' takes your patches in mbox format and commits them in. With 
description and all.

I just save the emails from the mail client and then apply them all in one go 
with 'git am -s'.


>c) No integration with continuous testing systems

There is no continuous testing at all now.

 But if you want - the 0-day build system picks up emails posted on LKML and 
compiles them to at least test that are compilable.

>
>
>
>
>
>___
>Grub-devel mailing list
>Grub-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/grub-devel



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GNU GRUB maintenance

[Konrad Rzeszutek Wilk]

On Fri, Oct 09, 2015 at 08:30:01PM -0400, Konrad Rzeszutek Wilk wrote:
> On October 9, 2015 8:14:39 AM EDT, "Vladimir 'φ-coder/phcoder' Serbinenko" 
> <phco...@gmail.com> wrote:
> >On 08.10.2015 21:34, Konrad Rzeszutek Wilk wrote:
> >> On October 8, 2015 10:52:25 AM EDT, Andrei Borzenkov
> ><arvidj...@gmail.com> wrote:
> >>> On Thu, Oct 8, 2015 at 12:14 AM, Vladimir 'φ-coder/phcoder'
> >Serbinenko
> >>> <phco...@gmail.com> wrote:
> >>>> Hello, all. I'm sorry for not being available to do enough
> >>> maintenance
> >>>> for GRUB in last time but I was overbooked. Yet there is a good
> >news.
> >>> At
> >>>> Google there is a 20% project and GRUB has been approved as 20%
> >>> project
> >>>> for me. The goal is to have 2.02 released before the end of this
> >>> year.
> >>>> Other than the raw lack of time there is another issue which makes
> >>>> maintenance difficult: inefficient VCS.
> >>>
> >>> VCS is actually OK. The project of size Linux kernel seems to work

Looking at the grub2 mailing list there hasn't been a ton of patches.

And even if there is a pickup of it - is it going to be around 1K a
month or more like in 100s?

If it is going to be in 100~ or so per month - I would think that
the existing mechanism of:
 1) save email in mbox file
 2) at the end of day, 'git am -s' < mbox file.
 3) git push

Would work - it is a five minute job. (This is assuming that the patches
don't break a build and so on - if they do, then you can break this
up and complain to the folks that post patches that it does not
build,etc).

If you are thinking there is going to 1K or so then some automated
system makes sense... but if you are trying to get a release out before
the end of this year and only have 10 business days to do this
(20% of 40 week = 8 hours, and there are 10 weeks left), then I would
concentrate on the existing patches + review.



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GNU GRUB maintenance

[Konrad Rzeszutek Wilk]

On Wed, Oct 07, 2015 at 05:36:49PM -0400, SevenBits wrote:
> On Wednesday, October 7, 2015, Vladimir 'φ-coder/phcoder' Serbinenko <
> phco...@gmail.com> wrote:
> 
> > Hello, all. I'm sorry for not being available to do enough maintenance
> > for GRUB in last time but I was overbooked. Yet there is a good news. At
> > Google there is a 20% project and GRUB has been approved as 20% project
> > for me. The goal is to have 2.02 released before the end of this year.
> > Other than the raw lack of time there is another issue which makes
> > maintenance difficult: inefficient VCS. It requires me or someone with
> > privileges manually copy the patch. What other systems would be ok? It

What do you mean by 'copy the patch'? git am -s works nice?

> > obviously has to be a free software and hosted on free software-friendly
> > hosting. It also has to have an efficient 1-click merge (so that someone
> > with privileges can get any patch submitted to the system merged in
> > couple of clicks).
> 
> 
> 
> I know that git is pretty popular...

> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GNU GRUB maintenance

[Konrad Rzeszutek Wilk]

On Thu, Oct 08, 2015 at 01:24:50PM +0700, Fajar A. Nugraha wrote:
> On Thu, Oct 8, 2015 at 6:02 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>  wrote:
> > On 07.10.2015 23:36, SevenBits wrote:
> 
> >> What other systems would be ok? It
> >> obviously has to be a free software and hosted on free 
> >> software-friendly
> >> hosting. It also has to have an efficient 1-click merge (so that 
> >> someone
> >> with privileges can get any patch submitted to the system merged in
> >> couple of clicks).
> >>
> >>
> >>
> >> I know that git is pretty popular...
> >>
> > Git integration is a plus. Like gerrit: git based with a review system
> > on top of it.
> 
> Is "has to be a free software" an absolute requirement?

Also an kernel.org git account could be requested. It is there for
syslinux, dracut, bluetooth, etc. GRUB2 could be hosted there as well?

> 
> Github, the web, is not open source. However it uses git, adds
> features (like the "1-click merge" and organization), and free (to
> use) for open source projects.
> 
> Some open source projects hosted on github (and use the organization feature):
> https://github.com/zfsonlinux
> https://github.com/freeradius
> 
> Some open source projects using github as mirror:
> https://help.github.com/articles/about-github-mirrors/
> 
> Github help on web-based pull request:
> https://help.github.com/articles/using-pull-requests/
> https://help.github.com/articles/merging-a-pull-request/
> 
> The downside with github that I can think of, is that for efficient
> use of the "1-click merge" web interface, the pull request must be
> created from the github interface (and the discussion will happen
> there as well), as opposed to in the mailing list like what currently
> happen. Then again, if the intention is simply to provide
> "notification to the mailing list" (and no need to allow discussion
> participation FROM the mailing list on the pull requests), you could
> probably work around that by having a normal git account with
> mailing-list address "watching" your repository.
> 
> -- 
> Fajar
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GNU GRUB maintenance

[Konrad Rzeszutek Wilk]

On October 8, 2015 10:52:25 AM EDT, Andrei Borzenkov  
wrote:
>On Thu, Oct 8, 2015 at 12:14 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
>> Hello, all. I'm sorry for not being available to do enough
>maintenance
>> for GRUB in last time but I was overbooked. Yet there is a good news.
>At
>> Google there is a 20% project and GRUB has been approved as 20%
>project
>> for me. The goal is to have 2.02 released before the end of this
>year.
>> Other than the raw lack of time there is another issue which makes
>> maintenance difficult: inefficient VCS.
>
>VCS is actually OK. The project of size Linux kernel seems to work
>well using pull request e-mails. The disadvantages are
>
>- contributors must have repository available via Internet


That is quite easy nowadays. And you can always ask for signed tags if you are 
worried about repos being subverted.

>- contributors are trusted to actually submit pull request for branch
>that was reviewed




It is a disadvantage to trust people!?


>- it needs to be done locally and pushed


Or you can have different maintainers pushing the patches in if they are Acked 
or Reviewed.

Meaning the committee does not have to be the same person who reviews/acks it.

>
>>   It requires me
>or someone with
>> privileges manually copy the patch. What other systems would be ok?
>It
>> obviously has to be a free software and hosted on free
>software-friendly
>> hosting. It also has to have an efficient 1-click merge (so that
>someone
>> with privileges can get any patch submitted to the system merged in
>> couple of clicks).
>>
>>

Clicks? That sounds like a GUI thing. And it sounds like you need to have an 
admin to set it up, patch it occasionally, deal with spammers, etc.

What is wrong with the old mechanism of emails.

>
>It does not like like we have much choice. If we speak about free
>external hosting, this is probably github, gerrithub, gitlab. I do not
>know if any of them is considered friendly enough by FSF.
>
>If we speak about self hosting, then it is probably gerrit and
>reviewboard (I wish we could join KDE reviewboard, but grub hardly can
>be called KDE application ... :) )
>
>I am not thrilled by github workflows. From what I could gather
>gerrithub looks more appealing, but would love to hear from someone
>who actually used both.
>
>One problem is that none of them apparently allows reviewing by
>E-Mail. This worked (and probably works, just I'm no more involved)
>quite well in KDE reviewboard. This means all review must be done via
>web. For me it is rather disadvantage. Also merged requests are
>removed, which means history and past discussions are no more present.
>Which again is better using e-mail review.

Aye!

>
>___
>Grub-devel mailing list
>Grub-devel@gnu.org
>https://lists.gnu.org/mailman/listinfo/grub-devel



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Development practices?

[Konrad Rzeszutek Wilk]

On September 24, 2015 3:09:20 PM EDT, Andrei Borzenkov <arvidj...@gmail.com> 
wrote:
>
>
>Отправлено с iPhone
>
>> 22 сент. 2015 г., в 20:28, Konrad Rzeszutek Wilk
><konrad.w...@oracle.com> написал(а):
>> 
>>> On Fri, Sep 11, 2015 at 11:34:53AM -0400, Konrad Rzeszutek Wilk
>wrote:
>>> .. snip..
>>>>>>>>> From what I have gathered so far the not enough reviewers
>>>>>>>>> is tied in folks being overworked - so there simply was no
>>>>>>>>> point of posting on the mailing list as nobody had the time
>>>>>>>>> to review it or test it properly?
>>>>>>> 
>>>>>>> Hi Konrad,
>>>>>>> 
>>>>>>> back in 2008/2009 (when Marco Gerards gave over Maintainance to
>Robert
>>>>>>> Millan) there were indeed not much people actively reviewing
>code.
>>>>>>> 
>>>>>>> Active people on the mailing list was just given commit access.
>It was
>>>>>>> expected that they only commit stuff without posting which
>doesn't need
>>>>>>> a review and complies with the rules back at that time.
>>>>>>> 
>>>>>>> Due to me missing a few years on the mailing list, I can't tell
>you
>>>>>>> unfortunately how it compares to today.
>>>>>> 
>>>>>> Not much changes as far as I can tell.
>>>>> 
>>>>> OK.
>>>>> 
>>>>> What qualifies as needing an review? Personal preference by
>>>>> the patch author?
>>>> 
>>>> I suppose, common sense. When I was given commit access, it was for
>>>> "committing after review" so I still sent all patches to the list.
>Then it
>>>> happened that Vladimir dropped off list for a long time and I tried
>to pick
>>>> up obvious bug fixes from list or bug tracker to keep things going.
>>>> 
>>>> I would say, any non-trivial bug fix or feature change needs to be
>posted
>>>> first.
>>>> 
>>>> I would love to have every patch posted and reviewed bug given
>current level
>>>> of activity it is simply unrealistic.
>>> 
>>> I see. From my perspective we are paid to work on the hobbies (Xen,
>Linux, etc)
>>> so the activity level is high since we have 8 hours a day to focus
>on it
>>> (minus bug activities, lunch, etc).
>>> 
>>> While GRUB2 is all volunteer with whatever time can be spared?
>>> 
>>> What if the companies that employ the committers allowed one day a
>week
>>> to focus on GRUB2 review/maintaince/etc? Would that help?
>>> 
>>> Or is it unrealistic to expect that from committers employer's?
>> 
>> ping?
>
>You realize that commiters' employers most likely do no read this list,
>right?
>


True, but I hoped that the commiters's would forward this to their managers.

May I assume from your email that if you had one day a week it would allow you 
to make much more progress on reviews, commits and a release?

>
>>>> 
>>>>> Thank you for answering my questions!
>>>> 



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Development practices?

[Konrad Rzeszutek Wilk]

On Fri, Sep 11, 2015 at 11:34:53AM -0400, Konrad Rzeszutek Wilk wrote:
> .. snip..
> > >>>>> From what I have gathered so far the not enough reviewers
> > >>>>>is tied in folks being overworked - so there simply was no
> > >>>>>point of posting on the mailing list as nobody had the time
> > >>>>>to review it or test it properly?
> > >>>>>
> > >>>
> > >>>Hi Konrad,
> > >>>
> > >>>back in 2008/2009 (when Marco Gerards gave over Maintainance to Robert
> > >>>Millan) there were indeed not much people actively reviewing code.
> > >>>
> > >>>Active people on the mailing list was just given commit access. It was
> > >>>expected that they only commit stuff without posting which doesn't need
> > >>>a review and complies with the rules back at that time.
> > >>>
> > >>>Due to me missing a few years on the mailing list, I can't tell you
> > >>>unfortunately how it compares to today.
> > >>>
> > >>
> > >>Not much changes as far as I can tell.
> > >
> > >OK.
> > >
> > >What qualifies as needing an review? Personal preference by
> > >the patch author?
> > >
> > 
> > I suppose, common sense. When I was given commit access, it was for
> > "committing after review" so I still sent all patches to the list. Then it
> > happened that Vladimir dropped off list for a long time and I tried to pick
> > up obvious bug fixes from list or bug tracker to keep things going.
> > 
> > I would say, any non-trivial bug fix or feature change needs to be posted
> > first.
> > 
> > I would love to have every patch posted and reviewed bug given current level
> > of activity it is simply unrealistic.
> 
> I see. From my perspective we are paid to work on the hobbies (Xen, Linux, 
> etc)
> so the activity level is high since we have 8 hours a day to focus on it
> (minus bug activities, lunch, etc).
> 
> While GRUB2 is all volunteer with whatever time can be spared?
> 
> What if the companies that employ the committers allowed one day a week
> to focus on GRUB2 review/maintaince/etc? Would that help?
> 
> Or is it unrealistic to expect that from committers employer's?
> 

ping?
> > 
> > >Thank you for answering my questions!
> > >
> > 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Development practices?

[Konrad Rzeszutek Wilk]

On Fri, Sep 11, 2015 at 05:34:45PM +0300, Andrei Borzenkov wrote:
> 09.09.2015 20:47, Felix Zielcke пишет:
> >Am Dienstag, den 08.09.2015, 13:57 -0400 schrieb Konrad Rzeszutek Wilk:
> >>On Thu, Sep 03, 2015 at 03:34:29PM -0400, Konrad Rzeszutek Wilk
> >>wrote:
> >
> >>I don't know enough about the community (or the history) to
> >>>understand it but would very much appreciate input.
> >>>And if I have offended somebody with my questions + feeble
> >>>analysis: my deepest apologies - and please straighten me out!
> >>>
> >>>
> >>> From what I have gathered so far the not enough reviewers
> >>>is tied in folks being overworked - so there simply was no
> >>>point of posting on the mailing list as nobody had the time
> >>>to review it or test it properly?
> >>>
> >
> >Hi Konrad,
> >
> >back in 2008/2009 (when Marco Gerards gave over Maintainance to Robert
> >Millan) there were indeed not much people actively reviewing code.
> >
> >Active people on the mailing list was just given commit access. It was
> >expected that they only commit stuff without posting which doesn't need
> >a review and complies with the rules back at that time.
> >
> >Due to me missing a few years on the mailing list, I can't tell you
> >unfortunately how it compares to today.
> >
> 
> Not much changes as far as I can tell.

OK.

What qualifies as needing an review? Personal preference by
the patch author?

Thank you for answering my questions!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Development practices?

[Konrad Rzeszutek Wilk]

. snip..
> > From what I have gathered so far the not enough reviewers
> >is tied in folks being overworked - so there simply was no
> >point of posting on the mailing list as nobody had the time
> >to review it or test it properly?
> >
> >>>
> >>>Hi Konrad,
> >>>
> >>>back in 2008/2009 (when Marco Gerards gave over Maintainance to Robert
> >>>Millan) there were indeed not much people actively reviewing code.
> >>>
> >>>Active people on the mailing list was just given commit access. It was
> >>>expected that they only commit stuff without posting which doesn't need
> >>>a review and complies with the rules back at that time.
> >>>
> >>>Due to me missing a few years on the mailing list, I can't tell you
> >>>unfortunately how it compares to today.
> >>>
> >>
> >>Not much changes as far as I can tell.
> >
> >OK.
> >
> >What qualifies as needing an review? Personal preference by
> >the patch author?
> >
> 
> I suppose, common sense. When I was given commit access, it was for
> "committing after review" so I still sent all patches to the list. Then it
> happened that Vladimir dropped off list for a long time and I tried to pick
> up obvious bug fixes from list or bug tracker to keep things going.
> 
> I would say, any non-trivial bug fix or feature change needs to be posted
> first.
> 
> I would love to have every patch posted and reviewed bug given current level
> of activity it is simply unrealistic.

I see. From my perspective we are paid to work on the hobbies (Xen, Linux, etc)
so the activity level is high since we have 8 hours a day to focus on it
(minus bug activities, lunch, etc).

While GRUB2 is all volunteer with whatever time can be spared?

What if the companies that employ the committers allowed one day a week
to focus on GRUB2 review/maintaince/etc? Would that help?

Or is it unrealistic to expect that from committers employer's?

> 
> >Thank you for answering my questions!
> >
> 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Development practices?

[Konrad Rzeszutek Wilk]

On Thu, Sep 03, 2015 at 03:34:29PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,

Expanding the circle, including folks on the To list.

Colin had answered some so snipping thouse out.
> 
> I've noticed a couple of things that the community seems
> to be doing different than other open source projects and
> was wondering why? And also how to conform to this (or perhaps
> it is time to change?) so that ideas/releases/patches can move forward.
> 
.. snip..
> 
>  - Some patches have been posted and hadn't much any architecture
>feedback or review. I am referring to Daniel's multboot2
>extensions and the ARM multiboot implementation for example.
> 
>Is that due to the tradition (not sure if that is the right
>word) that there aren't enough reviewers so folks shouldn't
>expect reviews?
> 
.. snip..
> 
> 
> I don't know enough about the community (or the history) to
> understand it but would very much appreciate input.
> And if I have offended somebody with my questions + feeble
> analysis: my deepest apologies - and please straighten me out!
> 
> 
> From what I have gathered so far the not enough reviewers
> is tied in folks being overworked - so there simply was no
> point of posting on the mailing list as nobody had the time
> to review it or test it properly?
> 
> [*1]: My background is in Linux kernel and Xen Project.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable

[Konrad Rzeszutek Wilk]

On Fri, Aug 28, 2015 at 02:22:46AM -0600, Jan Beulich wrote:
  On 27.08.15 at 19:56, 426...@gmail.com wrote:
  If you advocate direct booting ( no boot loader)  on production machines I
  wont argue much, as long as there is good recovery tools to deal with
  failed boots (grub does this very well, I am not aware of anything
  comparable that is pure efi). however the other use case which care more
  about is dual booting. I am a novice when it comes to Xen, although
  otherwise competent. The test machines I have for playing with Xen are also
  used for other tests, some of which require raw hardware support, so I want
  the ability to use a boot menu.
 
 All EFI systems that I've seen so far have a boot manager. Are you
 saying there are vendors who remove that?

Worst. There are some where the boot managers coughcertain families of 
AMI based BIOSes/cough which delete all but the last boot entry to
only have _one_ boot entry per ESP. No DualBoot for you!

The 'boot manager' in question is an boot entry (F8 or F12), which does not
allow any changes (change the parameters, etc) - just select the entry.

Furthermore my recollection is Microsoft has a 'boot configuration manager'
after EFI boots - you hit F8 and you can select which options you want to
boot Windows with.

We need that functionality and we can't depend on EFI getting it right - 
hence need GRUB. It would be fantastic if everybody fixed their EFI firmware
but since some of these for SMI have 'O.E.M vendor should
put information here' (or whatever it says) - it makes me think they
don't care the sligthest after the product has been released.

And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware
because your firmware vendor is not following the EFI spec in spirit.'

Now that said - do you have suggestions on how to make this work
with GRUB in the picture?

Thank you.

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

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Sat, Aug 22, 2015 at 08:16:26AM +0300, Andrei Borzenkov wrote:
 21.08.2015 21:41, Konrad Rzeszutek Wilk пишет:
 
 Lets start with a list of priorities:
   - What are the most important platforms after x86?
 
 I suppose distribution-wise they are ARM and PPC. This means 5 different
 GRUB builds. MIPS seems to be still in use, at least there are patches and
 bug reports.

x86-32 (BIOS)
x86-EFI
ARM-32
ARM-64
ARM-EFI ?

PPC-32
PPC-64
?

 
   - What are the most important tests that MUST PASS all the time?
 
 All of them actually. There is one test that unfortunately is bound to fail
 unless built in controlled environment.

Can the test be skipped if the environment is not controlled?

 
   - Which ones have been FAILing for years?
 
 
 Hard to know, there are no published results.
 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 10:18:08AM -0700, Josef Bacik wrote:
 On 08/21/2015 10:11 AM, Konrad Rzeszutek Wilk wrote:
 On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
 On 07/20/2015 11:22 AM, Peter Jones wrote:
 Hi everyone,
 Is there a plan for when upcoming GNU GRUB releases will happen?
 
 As far as I can tell, the last official release on
 ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
 on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
 committed since that beta 18 months ago.
 
 In the mean time, nearly every Linux distro is shipping a package
 derived from the 2.02~beta2 release plus some number of patches,
 some from the upstream repo and some not, and it's cumbersome to rectify
 which ones aren't upstream vs which ones have been fixed upstream with
 /nearly/ the same patch, etc., with all the noise of so many patches
 since the release.
 
 I suspect this would be better for a lot of GRUB users if releases
 happened on a regular schedule, or if, relatively often (say once or
 twice per year), a release schedule that spans several weeks and
 organized some kind of alpha-beta-release progression were decided
 upon and followed.
 
 So, can we make a release process that happens according to some regular
 cadence?  What needs to be done to make regular releases happen?  Going
 for years with the patch volume GRUB sees without doing a release is
 really not good for anybody.
 
 
 I'd like to +1 this.  I think the tests are important for sure, but there's
 no reason we can't set a release cadence and at least cut an -rc1 and spend
 some time fixing up the test failures.  Facebook is going to be using grub2
 in our provisioning environment, we would like to have official builds
 rather than running from git.  Thanks,
 
 What is the tests that are needed? Surely as different distros we could
 pool some hardware together to make this work?
 
 
 There was just some mention of tests failing earlier in the thread, that's
 what I was talking about.

Right.
 
 What do GRUB maintainers think are the top tests that are needed and
 on what architectures? And do you have any ideas on how to automate it?
 
 We're automating testing internally by provisioning the different types of
 boxes we have with grub2.  Once I have the ipv6 and tcp window scaling stuff
 in I plan to have continuous testing on grub2 to make sure our use case
 doesn't get broken by somebody.  Thanks,

Fantastic! Would there by any way to get this reflector copied on the emails
on the testing?
 
 Josef
 
 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
 On 07/20/2015 11:22 AM, Peter Jones wrote:
 Hi everyone,
 Is there a plan for when upcoming GNU GRUB releases will happen?
 
 As far as I can tell, the last official release on
 ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
 on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
 committed since that beta 18 months ago.
 
 In the mean time, nearly every Linux distro is shipping a package
 derived from the 2.02~beta2 release plus some number of patches,
 some from the upstream repo and some not, and it's cumbersome to rectify
 which ones aren't upstream vs which ones have been fixed upstream with
 /nearly/ the same patch, etc., with all the noise of so many patches
 since the release.
 
 I suspect this would be better for a lot of GRUB users if releases
 happened on a regular schedule, or if, relatively often (say once or
 twice per year), a release schedule that spans several weeks and
 organized some kind of alpha-beta-release progression were decided
 upon and followed.
 
 So, can we make a release process that happens according to some regular
 cadence?  What needs to be done to make regular releases happen?  Going
 for years with the patch volume GRUB sees without doing a release is
 really not good for anybody.
 
 
 I'd like to +1 this.  I think the tests are important for sure, but there's
 no reason we can't set a release cadence and at least cut an -rc1 and spend
 some time fixing up the test failures.  Facebook is going to be using grub2
 in our provisioning environment, we would like to have official builds
 rather than running from git.  Thanks,

What is the tests that are needed? Surely as different distros we could
pool some hardware together to make this work?

What do GRUB maintainers think are the top tests that are needed and
on what architectures? And do you have any ideas on how to automate it?
 
 Josef
 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB release schedule?

[Konrad Rzeszutek Wilk]

On Fri, Aug 21, 2015 at 09:24:33PM +0300, Andrei Borzenkov wrote:
 21.08.2015 20:11, Konrad Rzeszutek Wilk пишет:
 On Fri, Aug 21, 2015 at 09:56:59AM -0700, Josef Bacik wrote:
 On 07/20/2015 11:22 AM, Peter Jones wrote:
 Hi everyone,
 Is there a plan for when upcoming GNU GRUB releases will happen?
 
 As far as I can tell, the last official release on
 ftp://ftp.gnu.org/gnu/grub/ was 2.00 on 28-Jun-2012, and the last beta
 on http://alpha.gnu.org/pub/gnu/grub/ for the next version was
 2.02~beta2 on 24-Dec-2013 .  There are (give or take) 471 patches
 committed since that beta 18 months ago.
 
 In the mean time, nearly every Linux distro is shipping a package
 derived from the 2.02~beta2 release plus some number of patches,
 some from the upstream repo and some not, and it's cumbersome to rectify
 which ones aren't upstream vs which ones have been fixed upstream with
 /nearly/ the same patch, etc., with all the noise of so many patches
 since the release.
 
 I suspect this would be better for a lot of GRUB users if releases
 happened on a regular schedule, or if, relatively often (say once or
 twice per year), a release schedule that spans several weeks and
 organized some kind of alpha-beta-release progression were decided
 upon and followed.
 
 So, can we make a release process that happens according to some regular
 cadence?  What needs to be done to make regular releases happen?  Going
 for years with the patch volume GRUB sees without doing a release is
 really not good for anybody.
 
 
 I'd like to +1 this.  I think the tests are important for sure, but there's
 no reason we can't set a release cadence and at least cut an -rc1 and spend
 some time fixing up the test failures.  Facebook is going to be using grub2
 in our provisioning environment, we would like to have official builds
 rather than running from git.  Thanks,
 
 What is the tests that are needed? Surely as different distros we could
 pool some hardware together to make this work?
 
 What do GRUB maintainers think are the top tests that are needed and
 on what architectures? And do you have any ideas on how to automate it?
 
 
 GRUB includes comprehensive amount of regression tests. Just run make
 check. The practical problems are
 
 - many tests require additional tools (filesystem tests need at least mkfs
 for respective file system, LVM etc)
 
 - each platform must be built separately; that requires either native system
 or cross tools (which itself may not be trivial). So I e.g. am limited to
 x86
 
 - tests are not really formalized, you get PASS/FAIL but what failed is up
 to human to understand
 
 - some tests require server part, e.g. to run anything involving HTTP server
 must be available
 
 - some tests are pretty heavy hit; it is better now when I have new hardware
 still I cannot dream running them continuously on my notebook ...
 
 Of course addition to regression testing is always welcome.

Lets start with a list of priorities:
 - What are the most important platforms after x86?
 - What are the most important tests that MUST PASS all the time?
 - Which ones have been FAILing for years? 

Surely if we weed out the most important cases that cover 99% that will
give the foundation for going out with a release?

 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/grub-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images

[Konrad Rzeszutek Wilk]

On Fri, Aug 14, 2015 at 01:57:01PM +0200, Daniel Kiper wrote:
 On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote:
  On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote:
   Add multiboot2 protocol support for relocatable images. Only GRUB2
   with relevant patches understands that feature. Older multiboot
 
  You may want to enumerate what those 'relevant' patches are.
 
   protocol (regardless of version) compatible loaders ignore it
   and everything works as usual.
  
   Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
   ---
xen/arch/x86/boot/head.S  |   46 
   +
xen/arch/x86/x86_64/asm-offsets.c |1 +
xen/include/xen/multiboot2.h  |   13 +++
3 files changed, 50 insertions(+), 10 deletions(-)
  
   diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
   index d484f68..2520e48 100644
   --- a/xen/arch/x86/boot/head.S
   +++ b/xen/arch/x86/boot/head.S
   @@ -81,6 +81,13 @@ multiboot1_header_end:
/* 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_phys(start), /* Min load address. */ \
 
  We could go straight to __start?
 
 This specifies lowest load address not entry point.

Ah right. And the __start can be moved somewhere inside the .text
code, while 'start' is always at offset 0. Thank you!

 
 Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 21/23] x86/boot: implement early command line parser in C

[Konrad Rzeszutek Wilk]

 +static void vga_parse(const char *cmdline, early_boot_opts_t *ebo)
 +{
 +const char *c;
 +int tmp;
 +size_t la;
 +static const char empty_chars_comma[] __text =  \n\r\t,;
 +static const char x[] __text = x;
 +static const char vga[] __text = vga=;
 +static const char vga_current[] __text = current;
 +static const char vga_gfx[] __text = gfx-;
 +static const char vga_mode[] __text = mode-;
 +static const char vga_text_80x[] __text = text-80x;
 +
 +c = find_opt(cmdline, vga, 1);
 +
 +if ( !c )
 +return;
 +
 +ebo-boot_vid_mode = ASK_VGA;
 +
 +c += strlen_static(vga);
 +la = strcspn(c, empty_chars_comma);
 +
 +if ( !strncmp(c, vga_current, max(la, strlen_static(vga_current))) )
 +ebo-boot_vid_mode = VIDEO_CURRENT_MODE;
 +else if ( !strncmp(c, vga_text_80x, strlen_static(vga_text_80x)) )
 +{
 +c += strlen_static(vga_text_80x);
 +ebo-boot_vid_mode = rows2vmode(strtoi(c, empty_chars_comma, NULL));
 +}
 +else if ( !strncmp(c, vga_gfx, strlen_static(vga_gfx)) )
 +{
 +tmp = strtoi(c + strlen_static(vga_gfx), x, c);
 +
 +if ( tmp  0 || tmp  U16_MAX )
 +return;
 +
 +ebo-vesa_size[VESA_WIDTH] = tmp;
 +
 +tmp = strtoi(++c, x, c);

My ancient OL5 installation:



Choked on that with:
gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing 
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-fno-stack-protector -fno-exceptions -Werror -fno-builtin -msoft-float  -c 
-fpic cmdline.c -o cmdline.o
cc1: warnings being treated as errors
cmdline.c: In function ‘vga_parse’:
cmdline.c:363: warning: operation on ‘c’ may be undefined

Moving the ++c before the tmp assigment make the compiler happy.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable

[Konrad Rzeszutek Wilk]

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

s/next patch/x86: add multiboot2 protocol support for relocatable image.
 
 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 beginning and end of required memory region if it live at
 address not aligned to 2 MiB,
   - %ebp register is used as a storage for Xen image base address; this way
 we can get this value very quickly if it is needed; however, %ebp register
 is not used directly to access a given memory region,
   - %fs register is filled with segment descriptor which describes memory 
 region
 with Xen image (it could be relocated or not); it is used to access some 
 of

'memory region with Xen image' ? Not sure I follow?

Perhaps:
segment descriptor which starts (0) at Xen image base (_start).


 Xen data in early boot code; potentially we can use above mentioned 
 segment
 descriptor to access data using %ds:%esi and/or %es:%esi (e.g. movs*); 
 however,
 I think that it could unnecessarily obfuscate code (e.g. we need at least
 to operations to reload a given segment descriptor) and current solution

s/to/two/ ?
 looks quite optimal.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
  xen/arch/x86/Makefile  |6 +-
  xen/arch/x86/Rules.mk  |4 +
  xen/arch/x86/boot/head.S   |  165 
 ++--
  xen/arch/x86/boot/trampoline.S |   11 ++-
  xen/arch/x86/boot/wakeup.S |6 +-
  xen/arch/x86/boot/x86_64.S |   34 -
  xen/arch/x86/setup.c   |   33 
  xen/arch/x86/x86_64/mm.c   |2 +-
  xen/arch/x86/xen.lds.S |2 +-
  xen/include/asm-x86/config.h   |3 +
  xen/include/asm-x86/page.h |2 +-
  11 files changed, 182 insertions(+), 86 deletions(-)
 
 diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
 index 82c5a93..93069a8 100644
 --- a/xen/arch/x86/Makefile
 +++ b/xen/arch/x86/Makefile
 @@ -72,8 +72,10 @@ efi-$(x86_64) := $(shell if [ ! -r 
 $(BASEDIR)/include/xen/compile.h -o \
   echo '$(TARGET).efi'; fi)
  
  $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 - ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
 - `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
 +#THIS IS UGLY HACK! PLEASE DO NOT COMPLAIN. I WILL FIX IT IN NEXT 
 RELEASE.

OK :-)

 + ./boot/mkelf32 $(TARGET)-syms $(TARGET) $(XEN_IMG_PHYS_START) 
 0x82d08100
 +#./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
 +#`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
  
  
  ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
 $(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
 diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
 index 4a04a8a..7ccb8a0 100644
 --- a/xen/arch/x86/Rules.mk
 +++ b/xen/arch/x86/Rules.mk
 @@ -15,6 +15,10 @@ HAS_GDBSX := y
  HAS_PDX := y
  xenoprof := y
  
 +XEN_IMG_PHYS_START = 0x20
 +
 +CFLAGS += -DXEN_IMG_PHYS_START=$(XEN_IMG_PHYS_START)
 +
  CFLAGS += -I$(BASEDIR)/include 
  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
 index 3f1054d..d484f68 100644
 --- a/xen/arch/x86/boot/head.S
 +++ b/xen/arch/x86/boot/head.S
 @@ -12,13 +12,15 @@
  .text
  .code32
  
 -#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
 +#define sym_phys(sym) ((sym) - __XEN_VIRT_START + XEN_IMG_PHYS_START - 
 XEN_IMG_OFFSET)
 +#define sym_offset(sym)   ((sym) - __XEN_VIRT_START)
  
  #define BOOT_CS320x0008
  #define BOOT_CS640x0010
  #define BOOT_DS  0x0018
  #define BOOT_PSEUDORM_CS 0x0020
  #define BOOT_PSEUDORM_DS 0x0028
 +#define BOOT_FS  0x0030
  
  #define MB2_HT(name)  (MULTIBOOT2_HEADER_TAG_##name)
  #define MB2_TT(name)  (MULTIBOOT2_TAG_TYPE_##name)
 @@ -105,12 +107,13 @@ multiboot1_header_end:
  
  .word   0
  gdt_boot_descr:
 -   

Re: [PATCH v2 20/23] x86: add multiboot2 protocol support for EFI platforms

[Konrad Rzeszutek Wilk]

 +run_bs:
 +push%rax
 +push%rdi
 +
 +/* Initialize BSS (no nasty surprises!). */
 +lea __bss_start(%rip),%rdi
 +lea __bss_end(%rip),%rcx
 +sub %rdi,%rcx
 +shr $3,%rcx
 +xor %eax,%eax
 +rep stosq


This means we are using the %es segment. The multiboot1 is pretty clear
that it should cover up to 4GB.

Would it be worth adding a comment about that?

 +
 +pop %rdi
 +
 +/*
 + * IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable.
 + * OUT: %rax - multiboot2.mem_lower. Do not get this value from
 + * MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag. It could be bogus on
 + * EFI platforms.
 + */
 +callefi_multiboot2

However the function prototype for efi_multiboot2 is 'void', not 'int' - so
it would not return anything!


 +
 +/* Convert multiboot2.mem_lower to bytes/16. */

Should we check to make sure it is valid? With those weird machines you seem to 
have
run into I am not actually sure what a valid value is :-(

.. snip..

 diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
 index c5ae369..d30fe89 100644
 --- a/xen/arch/x86/efi/stub.c
 +++ b/xen/arch/x86/efi/stub.c
 @@ -13,6 +13,11 @@ struct efi __read_mostly efi = {
   .smbios3 = EFI_INVALID_TABLE_ADDR
  };
  
 +void __init efi_multiboot2(void)

unsigned int __init ..
 +{
 +/* TODO: Fail if entered! */

And maybe just 'return 0'; ?

 +}

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:35:49PM +0200, Daniel Kiper wrote:
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

but really - this is quite easy to review :-)

 ---
  .gitignore |3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/.gitignore b/.gitignore
 index 18ab8e8..6d25d39 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -147,6 +147,7 @@ mod-*.c
  missing
  netboot_test
  *.o
 +*.orig
  *.a
  ohci_test
  partmap_test
 @@ -160,9 +161,11 @@ po/stamp-po
  printf_test
  priority_queue_unit_test
  pseries_test
 +*.rej
  stamp-h
  stamp-h1
  stamp-h.in
 +*.swp
  symlist.c
  symlist.h
  trigtables.c
 -- 
 1.7.10.4
 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 23/23] x86: add multiboot2 protocol support for relocatable images

[Konrad Rzeszutek Wilk]

 MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI649
 +#define MULTIBOOT2_HEADER_TAG_RELOCATABLE10
  
  /* 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


Would be good for all of this (with the other MULTIBOOT2..)
to be aligned on the same column-ish.

 +
  /* Header console tag console_flags. */
  #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED1
  #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED  2
 @@ -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_BASE_ADDR21
  
  /* Multiboot 2 tag alignment. */
  #define MULTIBOOT2_TAG_ALIGN 8
 @@ -120,6 +127,12 @@ typedef struct {
  typedef struct {
  u32 type;
  u32 size;
 +u32 base_addr;
 +} multiboot2_tag_base_addr_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
  char string[0];
  } multiboot2_tag_string_t;
  
 -- 
 1.7.10.4
 

Otherwise, Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 5/6] multiboot2: Add support for relocatable images

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:35:53PM +0200, Daniel Kiper wrote:

This parts needs a bit of details I think.

As in why can't the ELF note that is present in the binary
be satisfied. Or under what conditions would the existing code
not work?

 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
  grub-core/loader/i386/multiboot_mbi.c |6 ++--
  grub-core/loader/multiboot.c  |   12 +--
  grub-core/loader/multiboot_elfxx.c|   28 +++
  grub-core/loader/multiboot_mbi2.c |   63 
 +
  include/grub/multiboot.h  |4 ++-
  include/multiboot2.h  |   24 +
  6 files changed, 118 insertions(+), 19 deletions(-)
 
 diff --git a/grub-core/loader/i386/multiboot_mbi.c 
 b/grub-core/loader/i386/multiboot_mbi.c
 index 956d0e3..abdb98b 100644
 --- a/grub-core/loader/i386/multiboot_mbi.c
 +++ b/grub-core/loader/i386/multiboot_mbi.c
 @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
grub_err_t err;
if (grub_multiboot_quirks  GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
  {
 -  err = grub_multiboot_load_elf (file, filename, buffer);
 +  err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
 +  GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
if (err == GRUB_ERR_UNKNOWN_OS  (header-flags  
 MULTIBOOT_AOUT_KLUDGE))
   grub_errno = err = GRUB_ERR_NONE;
  }
 @@ -118,7 +119,8 @@ load_kernel (grub_file_t file, const char *filename,
return GRUB_ERR_NONE;
  }
  
 -  return grub_multiboot_load_elf (file, filename, buffer);
 +  return grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
 +   GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);

Oh boy. That is a bit hard to read. Perhaps another function could be 
introduced?

grub_multiboot_load_elf_ignore_reloc ? which would just pass the three
parameters and set the rest to the 0 options?


  }
  
  static struct multiboot_header *
 diff --git a/grub-core/loader/multiboot.c b/grub-core/loader/multiboot.c
 index ca7154f..1b1f7a9 100644
 --- a/grub-core/loader/multiboot.c
 +++ b/grub-core/loader/multiboot.c
 @@ -190,12 +190,18 @@ static grub_uint64_t highest_load;
  /* Load ELF32 or ELF64.  */
  grub_err_t
  grub_multiboot_load_elf (grub_file_t file, const char *filename,
 -  void *buffer)
 +  void *buffer, int relocatable, grub_uint32_t min_addr,
 +  grub_uint32_t max_addr, grub_size_t align, 
 grub_uint32_t preference,
 +  grub_uint32_t *base_addr, int avoid_efi_boot_services)

s/int/bool/ ?

  {
if (grub_multiboot_is_elf32 (buffer))
 -return grub_multiboot_load_elf32 (file, filename, buffer);
 +return grub_multiboot_load_elf32 (file, filename, buffer, relocatable,
 +   min_addr, max_addr, align, preference,
 +   base_addr, avoid_efi_boot_services);
else if (grub_multiboot_is_elf64 (buffer))
 -return grub_multiboot_load_elf64 (file, filename, buffer);
 +return grub_multiboot_load_elf64 (file, filename, buffer, relocatable,
 +   min_addr, max_addr, align, preference,
 +   base_addr, avoid_efi_boot_services);
  
return grub_error (GRUB_ERR_UNKNOWN_OS, N_(invalid arch-dependent ELF 
 magic));
  }
 diff --git a/grub-core/loader/multiboot_elfxx.c 
 b/grub-core/loader/multiboot_elfxx.c
 index 6a220bd..4fce685 100644
 --- a/grub-core/loader/multiboot_elfxx.c
 +++ b/grub-core/loader/multiboot_elfxx.c
 @@ -51,7 +51,10 @@ CONCAT(grub_multiboot_is_elf, XX) (void *buffer)
  }
  
  static grub_err_t
 -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, 
 void *buffer)
 +CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename,
 +  void *buffer, int relocatable, 
 grub_uint32_t min_addr,
 +  grub_uint32_t max_addr, grub_size_t align, 
 grub_uint32_t preference,
 +  grub_uint32_t *base_addr, int 
 avoid_efi_boot_services)
  {
Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
char *phdr_base;
 @@ -89,19 +92,30 @@ CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, 
 const char *filename, voi
 if (phdr(i)-p_paddr + phdr(i)-p_memsz  highest_load)
   highest_load = phdr(i)-p_paddr + phdr(i)-p_memsz;
  
 -   grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, 
 memsz=0x%lx, vaddr=0x%lx\n,
 - i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz, 
 (long) phdr(i)-p_vaddr);
 +   grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, 
 memsz=0x%lx, vaddr=0x%lx,
 + align=0x%lx, relocatable=%d, 
 avoid_efi_boot_services=%d\n, i,

%d to %s 
 + (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz, 
 (long) phdr(i)-p_vaddr,
 + 

Re: [PATCH v2 4/6] multiboot2: Add tags used to pass ImageHandle to loaded image

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:35:52PM +0200, Daniel Kiper wrote:
 Add tags used to pass ImageHandle to loaded image. It is used

s/loaded image/loaded image if requested./
 by at least ExitBootServices() function.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
  grub-core/loader/multiboot_mbi2.c |   46 
 +
  include/multiboot2.h  |   16 +
  2 files changed, 53 insertions(+), 9 deletions(-)
 
 diff --git a/grub-core/loader/multiboot_mbi2.c 
 b/grub-core/loader/multiboot_mbi2.c
 index 8d66e3f..dc9c709 100644
 --- a/grub-core/loader/multiboot_mbi2.c
 +++ b/grub-core/loader/multiboot_mbi2.c
 @@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char 
 *filename)
 case MULTIBOOT_TAG_TYPE_NETWORK:
 case MULTIBOOT_TAG_TYPE_EFI_MMAP:
 case MULTIBOOT_TAG_TYPE_EFI_BS:
 +   case MULTIBOOT_TAG_TYPE_EFI32_IH:
 +   case MULTIBOOT_TAG_TYPE_EFI64_IH:
   break;
  
 default:
 @@ -407,16 +409,18 @@ grub_multiboot_get_mbi_size (void)
+ grub_get_multiboot_mmap_count ()
* sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
  + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), 
 MULTIBOOT_TAG_ALIGN)
 +#ifdef GRUB_MACHINE_EFI
  + ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
  + ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
 ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)

Shouldn't they be wrapped with #ifdef __x86_64__ (for efi64_ih) and #ifdef 
__i386__
for the other?

Or two functions (in the header?) wrapped with proper #ifdef machinery?

 ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
 ++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
 + + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
 +#endif
  + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
   + sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
  + acpiv2_size ()
  + net_size ()
 -#ifdef GRUB_MACHINE_EFI
 -+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
 - + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
 -#endif
  + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
  + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
  }
 @@ -906,11 +910,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
  
if (keep_bs)
  {
 -  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
 -  tag-type = MULTIBOOT_TAG_TYPE_EFI_BS;
 -  tag-size = sizeof (struct multiboot_tag);
 -  ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 - / sizeof (grub_properly_aligned_t);
 +  {
 + struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
 + tag-type = MULTIBOOT_TAG_TYPE_EFI_BS;
 + tag-size = sizeof (struct multiboot_tag);
 + ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 +   / sizeof (grub_properly_aligned_t);
 +  }
 +
 +#ifdef __x86_64__
 +  {
 + struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) 
 ptrorig;
 + tag-type = MULTIBOOT_TAG_TYPE_EFI64_IH;
 + tag-size = sizeof (*tag);

The other places where sizeof is used ends up using the full structure so it :

sizeof (struct multiboot_tag_efi64_ih)

 + tag-pointer = (grub_addr_t) grub_efi_image_handle;
 + ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 +   / sizeof (grub_properly_aligned_t);
 +  }
 +#endif
 +
 +#ifdef __i386__
 +  {
 + struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) 
 ptrorig;
 + tag-type = MULTIBOOT_TAG_TYPE_EFI32_IH;
 + tag-size = sizeof (*tag);

Ditto.
 + tag-pointer = (grub_addr_t) grub_efi_image_handle;
 + ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 +   / sizeof (grub_properly_aligned_t);
 +  }
 +#endif
  }
  #endif
  
 diff --git a/include/multiboot2.h b/include/multiboot2.h
 index b3977e3..9f97ddc 100644
 --- a/include/multiboot2.h
 +++ b/include/multiboot2.h
 @@ -60,6 +60,8 @@
  #define MULTIBOOT_TAG_TYPE_NETWORK   16
  #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17
  #define MULTIBOOT_TAG_TYPE_EFI_BS18
 +#define MULTIBOOT_TAG_TYPE_EFI32_IH  19
 +#define MULTIBOOT_TAG_TYPE_EFI64_IH  20
  
  #define MULTIBOOT_HEADER_TAG_END  0
  #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
 @@ -379,6 +381,20 @@ struct multiboot_tag_efi_mmap
multiboot_uint8_t efi_mmap[0];
  }; 
  
 +struct multiboot_tag_efi32_ih
 +{
 +  multiboot_uint32_t type;
 +  multiboot_uint32_t size;
 +  multiboot_uint32_t pointer;
 +};
 +
 +struct multiboot_tag_efi64_ih
 +{
 +  multiboot_uint32_t type;
 +  multiboot_uint32_t size;
 +  multiboot_uint64_t pointer;
 +};
 +
  #endif /* ! ASM_FILE */
  
  #endif /* ! MULTIBOOT_HEADER */
 -- 
 1.7.10.4
 

___
Grub-devel mailing list

Re: [PATCH v2 6/6] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:35:54PM +0200, Daniel Kiper wrote:
 Do not pass memory maps to image if it asked for EFI boot services. Maps are
 usually invalid in that case and they can confuse potential user. Image should
 get memory map itself just before ExitBootServices() call.

Can we point to some commits in Linux or Xen in which these situations
arose? 

Wait, I think there even was one commit in grub.

Aha:

ommit e75fdee420a7ad95e9a465c9699adc2e2e970440
Author: Vladimir 'phcoder' Serbinenko phco...@gmail.com
Date:   Tue Mar 26 11:34:56 2013 +0100

* grub-core/kern/efi/mm.c (grub_efi_finish_boot_services):
Try terminating EFI services several times due to quirks in some
implementations.

Otherwise:

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
  grub-core/loader/multiboot_mbi2.c |   71 
 ++---
  1 file changed, 35 insertions(+), 36 deletions(-)
 
 diff --git a/grub-core/loader/multiboot_mbi2.c 
 b/grub-core/loader/multiboot_mbi2.c
 index 7ac64ec..26e955c 100644
 --- a/grub-core/loader/multiboot_mbi2.c
 +++ b/grub-core/loader/multiboot_mbi2.c
 @@ -431,7 +431,7 @@ static grub_size_t
  grub_multiboot_get_mbi_size (void)
  {
  #ifdef GRUB_MACHINE_EFI
 -  if (!efi_mmap_size)
 +  if (!keep_bs  !efi_mmap_size)
  find_efi_mmap_size ();
  #endif
return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
 @@ -805,12 +805,13 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
}
}
  
 -  {
 -struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
 -grub_fill_multiboot_mmap (tag);
 -ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 -  / sizeof (grub_properly_aligned_t);
 -  }
 +  if (!keep_bs)
 +{
 +  struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
 +  grub_fill_multiboot_mmap (tag);
 +  ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 + / sizeof (grub_properly_aligned_t);
 +}
  
{
  struct multiboot_tag_elf_sections *tag
 @@ -826,18 +827,19 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
/ sizeof (grub_properly_aligned_t);
}
  
 -  {
 -struct multiboot_tag_basic_meminfo *tag
 -  = (struct multiboot_tag_basic_meminfo *) ptrorig;
 -tag-type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
 -tag-size = sizeof (struct multiboot_tag_basic_meminfo); 
 +  if (!keep_bs)
 +{
 +  struct multiboot_tag_basic_meminfo *tag
 + = (struct multiboot_tag_basic_meminfo *) ptrorig;
 +  tag-type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
 +  tag-size = sizeof (struct multiboot_tag_basic_meminfo);
  
 -/* Convert from bytes to kilobytes.  */
 -tag-mem_lower = grub_mmap_get_lower () / 1024;
 -tag-mem_upper = grub_mmap_get_upper () / 1024;
 -ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 -   / sizeof (grub_properly_aligned_t);
 -  }
 +  /* Convert from bytes to kilobytes.  */
 +  tag-mem_lower = grub_mmap_get_lower () / 1024;
 +  tag-mem_upper = grub_mmap_get_upper () / 1024;
 +  ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 + / sizeof (grub_properly_aligned_t);
 +}
  
{
  struct grub_net_network_level_interface *net;
 @@ -936,27 +938,24 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
  grub_efi_uintn_t efi_desc_size;
  grub_efi_uint32_t efi_desc_version;
  
 -tag-type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
 -tag-size = sizeof (*tag) + efi_mmap_size;
 -
  if (!keep_bs)
 -  err = grub_efi_finish_boot_services (efi_mmap_size, tag-efi_mmap, 
 NULL,
 -efi_desc_size, efi_desc_version);
 -else
{
 - if (grub_efi_get_memory_map (efi_mmap_size, (void *) tag-efi_mmap,
 -  NULL,
 -  efi_desc_size, efi_desc_version) = 0)
 -   err = grub_error (GRUB_ERR_IO, couldn't retrieve memory map);
 + tag-type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
 + tag-size = sizeof (*tag) + efi_mmap_size;
 +
 + err = grub_efi_finish_boot_services (efi_mmap_size, tag-efi_mmap, 
 NULL,
 +  efi_desc_size, efi_desc_version);
 +
 + if (err)
 +   return err;
 +
 + tag-descr_size = efi_desc_size;
 + tag-descr_vers = efi_desc_version;
 + tag-size = sizeof (*tag) + efi_mmap_size;
 +
 + ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 +   / sizeof (grub_properly_aligned_t);
}
 -if (err)
 -  return err;
 -tag-descr_size = efi_desc_size;
 -tag-descr_vers = efi_desc_version;
 -tag-size = sizeof (*tag) + efi_mmap_size;
 -
 -ptrorig += ALIGN_UP (tag-size, MULTIBOOT_TAG_ALIGN)
 -  / sizeof (grub_properly_aligned_t);
}
  
if (keep_bs)
 -- 
 1.7.10.4
 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub

Re: [PATCH v2 3/6] i386/relocator: Add grub_relocator64_efi relocator

[Konrad Rzeszutek Wilk]

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

Andrei, Valdimir: ping?

 
 If idea is accepted I will prepare grub_relocator32_efi relocator too.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
  grub-core/Makefile.core.def  |1 +
  grub-core/lib/i386/relocator.c   |   53 +++
  grub-core/lib/i386/relocator64_efi.S |   77 
 ++
  grub-core/loader/multiboot.c |   29 +++--
  grub-core/loader/multiboot_mbi2.c|   19 +++--
  include/grub/i386/multiboot.h|   11 +
  include/grub/i386/relocator.h|   21 ++
  include/multiboot2.h |9 
  8 files changed, 213 insertions(+), 7 deletions(-)
  create mode 100644 grub-core/lib/i386/relocator64_efi.S
 
 diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
 index a6101de..d583549 100644
 --- a/grub-core/Makefile.core.def
 +++ b/grub-core/Makefile.core.def
 @@ -1519,6 +1519,7 @@ module = {
x86 = lib/i386/relocator_common_c.c;
ieee1275 = lib/ieee1275/relocator.c;
efi = lib/efi/relocator.c;
 +  x86_64_efi = lib/i386/relocator64_efi.S;
mips = lib/mips/relocator_asm.S;
mips = lib/mips/relocator.c;
powerpc = lib/powerpc/relocator_asm.S;
 diff --git a/grub-core/lib/i386/relocator.c b/grub-core/lib/i386/relocator.c
 index 71dd4f0..459027e 100644
 --- a/grub-core/lib/i386/relocator.c
 +++ b/grub-core/lib/i386/relocator.c
 @@ -69,6 +69,19 @@ extern grub_uint64_t grub_relocator64_rsi;
  extern grub_addr_t grub_relocator64_cr3;
  extern struct grub_i386_idt grub_relocator16_idt;
  
 +#ifdef GRUB_MACHINE_EFI
 +#ifdef __x86_64__
 +extern grub_uint8_t grub_relocator64_efi_start;
 +extern grub_uint8_t grub_relocator64_efi_end;
 +extern grub_uint64_t grub_relocator64_efi_rax;
 +extern grub_uint64_t grub_relocator64_efi_rbx;
 +extern grub_uint64_t grub_relocator64_efi_rcx;
 +extern grub_uint64_t grub_relocator64_efi_rdx;
 +extern grub_uint64_t grub_relocator64_efi_rip;
 +extern grub_uint64_t grub_relocator64_efi_rsi;
 +#endif
 +#endif
 +
  #define RELOCATOR_SIZEOF(x)  (grub_relocator##x##_end - 
 grub_relocator##x##_start)
  
  grub_err_t
 @@ -214,3 +227,43 @@ grub_relocator64_boot (struct grub_relocator *rel,
/* Not reached.  */
return GRUB_ERR_NONE;
  }
 +
 +#ifdef GRUB_MACHINE_EFI
 +#ifdef __x86_64__
 +grub_err_t
 +grub_relocator64_efi_boot (struct grub_relocator *rel,
 +struct grub_relocator64_efi_state state)
 +{
 +  grub_err_t err;
 +  void *relst;
 +  grub_relocator_chunk_t ch;
 +
 +  err = grub_relocator_alloc_chunk_align (rel, ch, 0,
 +   0x4000 - RELOCATOR_SIZEOF 
 (64_efi),
 +   RELOCATOR_SIZEOF (64_efi), 16,
 +   GRUB_RELOCATOR_PREFERENCE_NONE, 1);
 +  if (err)
 +return err;
 +
 +  grub_relocator64_efi_rax = state.rax;
 +  grub_relocator64_efi_rbx = state.rbx;
 +  grub_relocator64_efi_rcx = state.rcx;
 +  grub_relocator64_efi_rdx = state.rdx;
 +  grub_relocator64_efi_rip = state.rip;
 +  grub_relocator64_efi_rsi = state.rsi;
 +
 +  grub_memmove (get_virtual_current_address (ch), 
 grub_relocator64_efi_start,
 + RELOCATOR_SIZEOF (64_efi));
 +
 +  err = grub_relocator_prepare_relocs (rel, get_physical_target_address (ch),
 +relst, NULL);
 +  if (err)
 +return err;
 +
 +  ((void (*) (void)) relst) ();
 +
 +  /* Not reached.  */
 +  return GRUB_ERR_NONE;
 +}
 +#endif
 +#endif
 diff --git a/grub-core/lib/i386/relocator64_efi.S 
 b/grub-core/lib/i386/relocator64_efi.S
 new file mode 100644
 index 000..fcd1964
 --- /dev/null
 +++ b/grub-core/lib/i386/relocator64_efi.S
 @@ -0,0 +1,77 @@
 +/*
 + *  GRUB  --  GRand Unified Bootloader
 + *  Copyright (C) 2009,2010  Free Software Foundation, Inc.
 + *  Copyright (C) 2014,2015  Oracle Co.
 + *  Author: Daniel Kiper
 + *
 + *  GRUB is free software: you can redistribute it and/or modify
 + *  it under the terms of the GNU General Public License as published by
 + *  the Free Software Foundation, either version 3 of the License, or
 + *  (at your option) any later version.
 + *
 + *  GRUB is distributed in the hope that it will be useful,
 + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *  GNU General Public 

Re: [Xen-devel] [PATCH v2 07/23] x86/boot/reloc: Rename some variables and rearrange code a bit

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:02PM +0200, Daniel Kiper wrote:
 Rename mbi and mbi_old variables and rearrange code a bit to make

s/mbi_old/mbi_in/

Perhaps you want to say: rename mbi_old with mbi_in, and mbi with mbi_out

or better:

Replace mbi with mbi_out and mbi_old with mbi_in and ...


 it more readable. Additionally, this way multiboot (v1) protocol
 implementation and future multiboot2 protocol implementation will
 use the same variable naming convention.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- extract this change from main mutliboot2
  protocol implementation
  (suggested by Jan Beulich).
 ---
  xen/arch/x86/boot/reloc.c |   39 +--
  1 file changed, 21 insertions(+), 18 deletions(-)
 
 diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
 index 09fd540..feb1d72 100644
 --- a/xen/arch/x86/boot/reloc.c
 +++ b/xen/arch/x86/boot/reloc.c
 @@ -86,41 +86,44 @@ static u32 copy_string(u32 src)
  return copy_mem(src, p - src + 1);
  }
  
 -multiboot_info_t *reloc(u32 mbi_old)
 +multiboot_info_t *reloc(u32 mbi_in)
  {
 -multiboot_info_t *mbi = (multiboot_info_t *)copy_mem(mbi_old, 
 sizeof(*mbi));
  int i;
 +multiboot_info_t *mbi_out;
  
 -if ( mbi-flags  MBI_CMDLINE )
 -mbi-cmdline = copy_string(mbi-cmdline);
 +mbi_out = (multiboot_info_t *)copy_mem(mbi_in, sizeof(*mbi_out));
  
 -if ( mbi-flags  MBI_MODULES )
 +if ( mbi_out-flags  MBI_CMDLINE )
 +mbi_out-cmdline = copy_string(mbi_out-cmdline);
 +
 +if ( mbi_out-flags  MBI_MODULES )
  {
  module_t *mods;
  
 -mbi-mods_addr = copy_mem(mbi-mods_addr, mbi-mods_count * 
 sizeof(module_t));
 +mbi_out-mods_addr = copy_mem(mbi_out-mods_addr,
 +  mbi_out-mods_count * 
 sizeof(module_t));
  
 -mods = (module_t *)mbi-mods_addr;
 +mods = (module_t *)mbi_out-mods_addr;
  
 -for ( i = 0; i  mbi-mods_count; i++ )
 +for ( i = 0; i  mbi_out-mods_count; i++ )
  {
  if ( mods[i].string )
  mods[i].string = copy_string(mods[i].string);
  }
  }
  
 -if ( mbi-flags  MBI_MEMMAP )
 -mbi-mmap_addr = copy_mem(mbi-mmap_addr, mbi-mmap_length);
 +if ( mbi_out-flags  MBI_MEMMAP )
 +mbi_out-mmap_addr = copy_mem(mbi_out-mmap_addr, 
 mbi_out-mmap_length);
  
 -if ( mbi-flags  MBI_LOADERNAME )
 -mbi-boot_loader_name = copy_string(mbi-boot_loader_name);
 +if ( mbi_out-flags  MBI_LOADERNAME )
 +mbi_out-boot_loader_name = copy_string(mbi_out-boot_loader_name);
  
  /* Mask features we don't understand or don't relocate. */
 -mbi-flags = (MBI_MEMLIMITS |
 -   MBI_CMDLINE |
 -   MBI_MODULES |
 -   MBI_MEMMAP |
 -   MBI_LOADERNAME);
 +mbi_out-flags = (MBI_MEMLIMITS |
 +   MBI_CMDLINE |
 +   MBI_MODULES |
 +   MBI_MEMMAP |
 +   MBI_LOADERNAME);
  
 -return mbi;
 +return mbi_out;
  }
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 06/23] x86/boot: use %ecx instead of %eax

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:01PM +0200, Daniel Kiper wrote:
 Use %ecx instead of %eax to store low memory upper limit from EBDA.
 This way we do not wipe multiboot protocol identifier. It is needed
 in reloc() to differentiate between multiboot (v1) and
 multiboot2 protocol.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 Reviewed-by: Andrew Cooper andrew.coop...@citrix.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  xen/arch/x86/boot/head.S |   24 
  1 file changed, 12 insertions(+), 12 deletions(-)
 
 diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
 index 3cbb2e6..77e7da9 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,21 +106,21 @@ __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%ebx/* Multiboot information address. */
 -push%eax/* Boot trampoline address. */
 +push%ecx/* Boot trampoline address. */
  callreloc
  add $8,%esp /* Remove reloc() args from stack. */
  mov %eax,sym_phys(multiboot_ptr)
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 08/23] x86: add multiboot2 protocol support

[Konrad Rzeszutek Wilk]

 MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI328
 +#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI649
 +
 +/* Header tag flags. */
 +#define MULTIBOOT2_HEADER_TAG_REQUIRED   0
 +#define MULTIBOOT2_HEADER_TAG_OPTIONAL   1
 +
 +/* Header console tag console_flags. */
 +#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED1
 +#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED  2
 +
 +/* Flags set in the 'flags' member of the multiboot header.  */
 +#define MULTIBOOT2_TAG_TYPE_END  0
 +#define MULTIBOOT2_TAG_TYPE_CMDLINE  1
 +#define MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME 2
 +#define MULTIBOOT2_TAG_TYPE_MODULE   3
 +#define MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO4
 +#define MULTIBOOT2_TAG_TYPE_BOOTDEV  5
 +#define MULTIBOOT2_TAG_TYPE_MMAP 6
 +#define MULTIBOOT2_TAG_TYPE_VBE  7
 +#define MULTIBOOT2_TAG_TYPE_FRAMEBUFFER  8
 +#define MULTIBOOT2_TAG_TYPE_ELF_SECTIONS 9
 +#define MULTIBOOT2_TAG_TYPE_APM  10

In the grub code those all look actually in the same column.

I presume it is due to the '2'. But perhaps we can make this
whole file have the values at around the same column?

Also for the MULTIBOOT2_BOOTLOADER_MAGIC, ..MOD_ALIGN, INFO_ALIGN, etc.

 +#define MULTIBOOT2_TAG_TYPE_EFI3211
 +#define MULTIBOOT2_TAG_TYPE_EFI6412
 +#define MULTIBOOT2_TAG_TYPE_SMBIOS   13
 +#define MULTIBOOT2_TAG_TYPE_ACPI_OLD 14
 +#define MULTIBOOT2_TAG_TYPE_ACPI_NEW 15
 +#define MULTIBOOT2_TAG_TYPE_NETWORK  16
 +#define MULTIBOOT2_TAG_TYPE_EFI_MMAP 17
 +#define MULTIBOOT2_TAG_TYPE_EFI_BS   18
 +#define MULTIBOOT2_TAG_TYPE_EFI32_IH 19
 +#define MULTIBOOT2_TAG_TYPE_EFI64_IH 20
 +
 +/* Multiboot 2 tag alignment. */
 +#define MULTIBOOT2_TAG_ALIGN 8
 +
 +/* Memory types. */
 +#define MULTIBOOT2_MEMORY_AVAILABLE  1
 +#define MULTIBOOT2_MEMORY_RESERVED   2
 +#define MULTIBOOT2_MEMORY_ACPI_RECLAIMABLE   3
 +#define MULTIBOOT2_MEMORY_NVS4
 +#define MULTIBOOT2_MEMORY_BADRAM 5
 +
 +/* Framebuffer types. */
 +#define MULTIBOOT2_FRAMEBUFFER_TYPE_INDEXED  0
 +#define MULTIBOOT2_FRAMEBUFFER_TYPE_RGB  1
 +#define MULTIBOOT2_FRAMEBUFFER_TYPE_EGA_TEXT 2

And these.


Otherwise,

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 +
 +#ifndef __ASSEMBLY__
 +typedef struct {
 +u32 total_size;
 +u32 reserved;
 +} multiboot2_fixed_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +} multiboot2_tag_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +char string[0];
 +} multiboot2_tag_string_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +u32 mem_lower;
 +u32 mem_upper;
 +} multiboot2_tag_basic_meminfo_t;
 +
 +typedef struct __packed {
 +u64 addr;
 +u64 len;
 +u32 type;
 +u32 zero;
 +} multiboot2_memory_map_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +u32 entry_size;
 +u32 entry_version;
 +multiboot2_memory_map_t entries[0];
 +} multiboot2_tag_mmap_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +u64 pointer;
 +} multiboot2_tag_efi64_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +u64 pointer;
 +} multiboot2_tag_efi64_ih_t;
 +
 +typedef struct {
 +u32 type;
 +u32 size;
 +u32 mod_start;
 +u32 mod_end;
 +char cmdline[0];
 +} multiboot2_tag_module_t;
 +#endif /* __ASSEMBLY__ */
 +
 +#endif /* __MULTIBOOT2_H__ */
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 18/23] efi: split out efi_exit_boot()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:13PM +0200, Daniel Kiper wrote:
 ..which gets memory map and calls ExitBootServices(). We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   92 
 +++--
  1 file changed, 50 insertions(+), 42 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 04b9c7e..bf2f198 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -879,6 +879,53 @@ static void __init 
 efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
  efi_arch_video_init(gop, info_size, mode_info);
  }
  
 +static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
 +{
 +EFI_STATUS status;
 +UINTN info_size = 0, map_key;
 +bool_t retry;
 +
 +efi_bs-GetMemoryMap(info_size, NULL, map_key,
 + efi_mdesc_size, mdesc_ver);
 +info_size += 8 * efi_mdesc_size;
 +efi_memmap = efi_arch_allocate_mmap_buffer(info_size);
 +if ( !efi_memmap )
 +blexit(LUnable to allocate memory for EFI memory map);
 +
 +for ( retry = 0; ; retry = 1 )
 +{
 +efi_memmap_size = info_size;
 +status = SystemTable-BootServices-GetMemoryMap(efi_memmap_size,
 + efi_memmap, 
 map_key,
 + efi_mdesc_size,
 + mdesc_ver);
 +if ( EFI_ERROR(status) )
 +PrintErrMesg(LCannot obtain memory map, status);
 +
 +efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
 +efi_mdesc_size, mdesc_ver);
 +
 +efi_arch_pre_exit_boot();
 +
 +status = SystemTable-BootServices-ExitBootServices(ImageHandle,
 + map_key);
 +efi_bs = NULL;
 +if ( status != EFI_INVALID_PARAMETER || retry )
 +break;
 +}
 +
 +if ( EFI_ERROR(status) )
 +PrintErrMesg(LCannot exit boot services, status);
 +
 +/* Adjust pointers into EFI. */
 +efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
 +#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
 +efi_rs = (void *)efi_rs + DIRECTMAP_VIRT_START;
 +#endif
 +efi_memmap = (void *)efi_memmap + DIRECTMAP_VIRT_START;
 +efi_fw_vendor = (void *)efi_fw_vendor + DIRECTMAP_VIRT_START;
 +}
 +
  static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 
 *sz)
  {
 if ( bpp  0 )
 @@ -903,11 +950,11 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  EFI_STATUS status;
  unsigned int i, argc;
  CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
 -UINTN map_key, info_size, gop_mode = ~0;
 +UINTN gop_mode = ~0;
  EFI_SHIM_LOCK_PROTOCOL *shim_lock;
  EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
  union string section = { NULL }, name;
 -bool_t base_video = 0, retry;
 +bool_t base_video = 0;
  char *option_str;
  bool_t use_cfg_file;
  
 @@ -1125,46 +1172,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  
  efi_set_gop_mode(gop, gop_mode);
  
 -info_size = 0;
 -efi_bs-GetMemoryMap(info_size, NULL, map_key,
 - efi_mdesc_size, mdesc_ver);
 -info_size += 8 * efi_mdesc_size;
 -efi_memmap = efi_arch_allocate_mmap_buffer(info_size);
 -if ( !efi_memmap )
 -blexit(LUnable to allocate memory for EFI memory map);
 -
 -for ( retry = 0; ; retry = 1 )
 -{
 -efi_memmap_size = info_size;
 -status = SystemTable-BootServices-GetMemoryMap(efi_memmap_size,
 - efi_memmap, 
 map_key,
 - efi_mdesc_size,
 - mdesc_ver);
 -if ( EFI_ERROR(status) )
 -PrintErrMesg(LCannot obtain memory map, status);
 -
 -efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
 -efi_mdesc_size, mdesc_ver);
 -
 -efi_arch_pre_exit_boot();
 -
 -status = SystemTable-BootServices-ExitBootServices(ImageHandle,
 - map_key);
 -efi_bs = NULL;
 -if ( status != EFI_INVALID_PARAMETER || retry )
 -break;
 -}
 -
 -if ( EFI_ERROR(status) )
 -PrintErrMesg(LCannot exit boot services, status);
 -
 -/* Adjust pointers into EFI. */
 -efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
 -#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
 -efi_rs = (void *)efi_rs

Re: [PATCH v2 01/23] x86/boot: remove unneeded instruction

[Konrad Rzeszutek Wilk]

On Mon, Jul 27, 2015 at 09:46:08PM +0200, Daniel Kiper wrote:
 On Fri, Jul 24, 2015 at 12:22:57PM -0400, Konrad Rzeszutek Wilk wrote:
  On Mon, Jul 20, 2015 at 04:28:56PM +0200, Daniel Kiper wrote:
   Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 
  Don't you use it in:
 
  /* Switch to low-memory stack.  */
  193 mov sym_phys(trampoline_phys),%edi
  194 lea 0x1(%edi),%esp
  195 lea trampoline_boot_cpu_entry-trampoline_start(%edi),%eax
  ?
 
 Yep, but...
 
   ---
xen/arch/x86/boot/head.S |1 -
1 file changed, 1 deletion(-)
  
   diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
   index cfd59dc..f63b349 100644
   --- a/xen/arch/x86/boot/head.S
   +++ b/xen/arch/x86/boot/head.S
   @@ -169,7 +169,6 @@ __start:
/* Apply relocations to bootstrap trampoline. */
mov sym_phys(trampoline_phys),%edx
 
 ...relevant value is stored in sym_phys(trampoline_phys) earlier then it is
 read into %edx here and...
 
mov $sym_phys(__trampoline_rel_start),%edi
   -mov %edx,sym_phys(trampoline_phys)
 
 ...it is put back to sym_phys(trampoline_phys) without any change here :-))).
 So, I suppose this is remnant from something which was removed once but
 somebody forgot to remove this instruction too... This patch fixes it.

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 04/23] x86/boot: call reloc() using cdecl calling convention

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:28:59PM +0200, Daniel Kiper wrote:
 Suggested-by: Jan Beulich jbeul...@suse.com
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

 ---
  xen/arch/x86/boot/head.S  |4 +++-
  xen/arch/x86/boot/reloc.c |   20 
  2 files changed, 19 insertions(+), 5 deletions(-)
 
 diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
 index ed42782..3cbb2e6 100644
 --- a/xen/arch/x86/boot/head.S
 +++ b/xen/arch/x86/boot/head.S
 @@ -119,8 +119,10 @@ __start:
  
  /* Save the Multiboot info struct (after relocation) for later use. 
 */
  mov $sym_phys(cpu0_stack)+1024,%esp
 -push%ebx
 +push%ebx/* Multiboot information address. */
 +push%eax/* Boot trampoline address. */
  callreloc
 +add $8,%esp /* Remove reloc() args from stack. */
  mov %eax,sym_phys(multiboot_ptr)
  
  /* Initialize BSS (no nasty surprises!). */
 diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
 index 63045c0..708898f 100644
 --- a/xen/arch/x86/boot/reloc.c
 +++ b/xen/arch/x86/boot/reloc.c
 @@ -10,15 +10,27 @@
   *Keir Fraser k...@xen.org
   */
  
 -/* entered with %eax = BOOT_TRAMPOLINE */
 +/*
 + * This entry point is entered from xen/arch/x86/boot/head.S with:
 + *   - 0x4(%esp) = BOOT_TRAMPOLINE_ADDRESS,
 + *   - 0x8(%esp) = MULTIBOOT_INFORMATION_ADDRESS.
 + */
  asm (
  .text \n
  .globl _start \n
  _start:   \n
 +push %ebp \n
 +mov  %esp,%ebp\n
  call 1f   \n
 -1:  pop  %ebx \n
 -mov  %eax,alloc-1b(%ebx)  \n
 -jmp  reloc\n
 +1:  pop  %ecx \n
 +mov  0x8(%ebp),%eax   \n
 +mov  %eax,alloc-1b(%ecx)  \n
 +mov  0xc(%ebp),%eax   \n
 +push %eax \n
 +call reloc\n
 +add  $4,%esp  \n
 +pop  %ebp \n
 +ret   \n
  );
  
  /*
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 11/23] efi: split out efi_init()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:06PM +0200, Daniel Kiper wrote:
 ..which initializes basic EFI variables. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   28 +---
  1 file changed, 17 insertions(+), 11 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 1f188fe..6f327cd 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -595,6 +595,22 @@ static char *__init get_value(const struct file *cfg, 
 const char *section,
  return NULL;
  }
  
 +static void __init efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
 +{
 +efi_ih = ImageHandle;
 +efi_bs = SystemTable-BootServices;
 +efi_bs_revision = efi_bs-Hdr.Revision;
 +efi_rs = SystemTable-RuntimeServices;
 +efi_ct = SystemTable-ConfigurationTable;
 +efi_num_ct = SystemTable-NumberOfTableEntries;
 +efi_version = SystemTable-Hdr.Revision;
 +efi_fw_vendor = SystemTable-FirmwareVendor;
 +efi_fw_revision = SystemTable-FirmwareRevision;
 +
 +StdOut = SystemTable-ConOut;
 +StdErr = SystemTable-StdErr ?: StdOut;
 +}
 +
  static void __init setup_efi_pci(void)
  {
  EFI_STATUS status;
 @@ -721,18 +737,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  set_bit(EFI_PLATFORM, efi.flags);
  #endif
  
 -efi_ih = ImageHandle;
 -efi_bs = SystemTable-BootServices;
 -efi_bs_revision = efi_bs-Hdr.Revision;
 -efi_rs = SystemTable-RuntimeServices;
 -efi_ct = SystemTable-ConfigurationTable;
 -efi_num_ct = SystemTable-NumberOfTableEntries;
 -efi_version = SystemTable-Hdr.Revision;
 -efi_fw_vendor = SystemTable-FirmwareVendor;
 -efi_fw_revision = SystemTable-FirmwareRevision;
 +efi_init(ImageHandle, SystemTable);
  
 -StdOut = SystemTable-ConOut;
 -StdErr = SystemTable-StdErr ?: StdOut;
  use_cfg_file = efi_arch_use_config_file(SystemTable);
  
  status = efi_bs-HandleProtocol(ImageHandle, loaded_image_guid,
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 12/23] efi: split out efi_console_set_mode()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:07PM +0200, Daniel Kiper wrote:
 ..which sets console mode. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   37 -
  1 file changed, 20 insertions(+), 17 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 6f327cd..4614146 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -611,6 +611,25 @@ static void __init efi_init(EFI_HANDLE ImageHandle, 
 EFI_SYSTEM_TABLE *SystemTabl
  StdErr = SystemTable-StdErr ?: StdOut;
  }
  
 +static void __init efi_console_set_mode(void)
 +{
 +UINTN cols, rows, size;
 +unsigned int best, i;
 +
 +for ( i = 0, size = 0, best = StdOut-Mode-Mode;
 +  i  StdOut-Mode-MaxMode; ++i )
 +{
 +if ( StdOut-QueryMode(StdOut, i, cols, rows) == EFI_SUCCESS 
 + cols * rows  size )
 +{
 +size = cols * rows;
 +best = i;
 +}
 +}
 +if ( best != StdOut-Mode-Mode )
 +StdOut-SetMode(StdOut, best);
 +}
 +
  static void __init setup_efi_pci(void)
  {
  EFI_STATUS status;
 @@ -799,23 +818,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  }
  
  if ( !base_video )
 -{
 -unsigned int best;
 -UINTN cols, rows, size;
 -
 -for ( i = 0, size = 0, best = StdOut-Mode-Mode;
 -  i  StdOut-Mode-MaxMode; ++i )
 -{
 -if ( StdOut-QueryMode(StdOut, i, cols, rows) == 
 EFI_SUCCESS 
 - cols * rows  size )
 -{
 -size = cols * rows;
 -best = i;
 -}
 -}
 -if ( best != StdOut-Mode-Mode )
 -StdOut-SetMode(StdOut, best);
 -}
 +efi_console_set_mode();
  }
  
  PrintStr(LXen  __stringify(XEN_VERSION) . __stringify(XEN_SUBVERSION)
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 15/23] efi: split out efi_tables()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:10PM +0200, Daniel Kiper wrote:
 ..which collects system tables data. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   61 
 +++--
  1 file changed, 34 insertions(+), 27 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 8d16470..fd62125 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -717,6 +717,39 @@ static UINTN __init 
 efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
  return gop_mode;
  }
  
 +static void __init efi_tables(void)
 +{
 +unsigned int i;
 +
 +/* Obtain basic table pointers. */
 +for ( i = 0; i  efi_num_ct; ++i )
 +{
 +static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
 +static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
 +static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
 +static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
 +static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
 +
 +if ( match_guid(acpi2_guid, efi_ct[i].VendorGuid) )
 +efi.acpi20 = (long)efi_ct[i].VendorTable;
 +if ( match_guid(acpi_guid, efi_ct[i].VendorGuid) )
 +efi.acpi = (long)efi_ct[i].VendorTable;
 +if ( match_guid(mps_guid, efi_ct[i].VendorGuid) )
 +efi.mps = (long)efi_ct[i].VendorTable;
 +if ( match_guid(smbios_guid, efi_ct[i].VendorGuid) )
 +efi.smbios = (long)efi_ct[i].VendorTable;
 +if ( match_guid(smbios3_guid, efi_ct[i].VendorGuid) )
 +efi.smbios3 = (long)efi_ct[i].VendorTable;
 +}
 +
 +#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
 +dmi_efi_get_table(efi.smbios != EFI_INVALID_TABLE_ADDR
 +  ? (void *)(long)efi.smbios : NULL,
 +  efi.smbios3 != EFI_INVALID_TABLE_ADDR
 +  ? (void *)(long)efi.smbios3 : NULL);
 +#endif
 +}
 +
  static void __init setup_efi_pci(void)
  {
  EFI_STATUS status;
 @@ -1039,33 +1072,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  /* XXX Collect EDID info. */
  efi_arch_cpu();
  
 -/* Obtain basic table pointers. */
 -for ( i = 0; i  efi_num_ct; ++i )
 -{
 -static EFI_GUID __initdata acpi2_guid = ACPI_20_TABLE_GUID;
 -static EFI_GUID __initdata acpi_guid = ACPI_TABLE_GUID;
 -static EFI_GUID __initdata mps_guid = MPS_TABLE_GUID;
 -static EFI_GUID __initdata smbios_guid = SMBIOS_TABLE_GUID;
 -static EFI_GUID __initdata smbios3_guid = SMBIOS3_TABLE_GUID;
 -
 -if ( match_guid(acpi2_guid, efi_ct[i].VendorGuid) )
 -efi.acpi20 = (long)efi_ct[i].VendorTable;
 -if ( match_guid(acpi_guid, efi_ct[i].VendorGuid) )
 -efi.acpi = (long)efi_ct[i].VendorTable;
 -if ( match_guid(mps_guid, efi_ct[i].VendorGuid) )
 -efi.mps = (long)efi_ct[i].VendorTable;
 -if ( match_guid(smbios_guid, efi_ct[i].VendorGuid) )
 -efi.smbios = (long)efi_ct[i].VendorTable;
 -if ( match_guid(smbios3_guid, efi_ct[i].VendorGuid) )
 -efi.smbios3 = (long)efi_ct[i].VendorTable;
 -}
 -
 -#ifndef CONFIG_ARM /* TODO - disabled until implemented on ARM */
 -dmi_efi_get_table(efi.smbios != EFI_INVALID_TABLE_ADDR
 -  ? (void *)(long)efi.smbios : NULL,
 -  efi.smbios3 != EFI_INVALID_TABLE_ADDR
 -  ? (void *)(long)efi.smbios3 : NULL);
 -#endif
 +efi_tables();
  
  /* Collect PCI ROM contents. */
  setup_efi_pci();
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 09/23] efi: create efi_enabled()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:04PM +0200, Daniel Kiper wrote:
 We need more fine grained knowledge about EFI environment and check
 for EFI platform and EFI loader separately to properly support
 multiboot2 protocol. In general Xen loaded by this protocol uses
 memory mappings and loaded modules in similar way to Xen loaded
 by multiboot (v1) protocol. Hence, create efi_enabled() which
 checks available features in efi.flags. This patch only defines
 EFI_PLATFORM feature which is equal to old efi_enabled == 1.
 Following patch will define EFI_LOADER feature accordingly.
 
 Suggested-by: Jan Beulich jbeul...@suse.com
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  xen/arch/x86/dmi_scan.c|4 ++--
  xen/arch/x86/domain_page.c |2 +-
  xen/arch/x86/efi/stub.c|   11 ---
  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/arch/x86/xen.lds.S |2 --
  xen/common/efi/boot.c  |4 
  xen/common/efi/runtime.c   |   17 +++--
  xen/drivers/acpi/osl.c |2 +-
  xen/include/xen/efi.h  |   16 ++--
  12 files changed, 46 insertions(+), 30 deletions(-)
 
 diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
 index 269168c..95c5a77 100644
 --- a/xen/arch/x86/dmi_scan.c
 +++ b/xen/arch/x86/dmi_scan.c
 @@ -229,7 +229,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
  {
   static unsigned int __initdata instance;
  
 - if (efi_enabled) {
 + if (efi_enabled(EFI_PLATFORM)) {
   if (efi_smbios3_size  !(instance  1)) {
   *base = efi_smbios3_address;
   *len = efi_smbios3_size;
 @@ -693,7 +693,7 @@ static void __init dmi_decode(struct dmi_header *dm)
  
  void __init dmi_scan_machine(void)
  {
 - if ((!efi_enabled ? dmi_iterate(dmi_decode) :
 + if ((!efi_enabled(EFI_PLATFORM) ? dmi_iterate(dmi_decode) :
   dmi_efi_iterate(dmi_decode)) == 0)
   dmi_check_system(dmi_blacklist);
   else
 diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
 index d86f8fe..fdf0d8a 100644
 --- a/xen/arch/x86/domain_page.c
 +++ b/xen/arch/x86/domain_page.c
 @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
   * domain's page tables but current may point at another domain's VCPU.
   * Return NULL as though current is not properly set up yet.
   */
 -if ( efi_enabled  efi_rs_using_pgtables() )
 +if ( efi_enabled(EFI_PLATFORM)  efi_rs_using_pgtables() )
  return NULL;
  
  /*
 diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
 index 07c2bd0..c5ae369 100644
 --- a/xen/arch/x86/efi/stub.c
 +++ b/xen/arch/x86/efi/stub.c
 @@ -4,9 +4,14 @@
  #include xen/lib.h
  #include asm/page.h
  
 -#ifndef efi_enabled
 -const bool_t efi_enabled = 0;
 -#endif
 +struct efi __read_mostly efi = {
 + .flags   = 0, /* Initialized later. */
 + .acpi= EFI_INVALID_TABLE_ADDR,
 + .acpi20  = EFI_INVALID_TABLE_ADDR,
 + .mps = EFI_INVALID_TABLE_ADDR,
 + .smbios  = EFI_INVALID_TABLE_ADDR,
 + .smbios3 = EFI_INVALID_TABLE_ADDR
 +};
  
  void __init efi_init_memory(void) { }
  
 diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c
 index 8609f4a..5223579 100644
 --- a/xen/arch/x86/mpparse.c
 +++ b/xen/arch/x86/mpparse.c
 @@ -557,7 +557,7 @@ static inline void __init 
 construct_default_ISA_mptable(int mpc_default_type)
  
  static __init void efi_unmap_mpf(void)
  {
 - if (efi_enabled)
 + if (efi_enabled(EFI_PLATFORM))
   clear_fixmap(FIX_EFI_MPF);
  }
  
 @@ -715,7 +715,7 @@ void __init find_smp_config (void)
  {
   unsigned int address;
  
 - if (efi_enabled) {
 + if (efi_enabled(EFI_PLATFORM)) {
   efi_check_config();
   return;
   }
 diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
 index ff34670..bce708c 100644
 --- a/xen/arch/x86/setup.c
 +++ b/xen/arch/x86/setup.c
 @@ -444,8 +444,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_PLATFORM) )
  return;
  
  if ( (bvi-orig_video_isVGA == 1)  (bvi-orig_video_mode == 3) )
 @@ -695,7 +695,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  if ( !(mbi-flags  MBI_MODULES) || (mbi-mods_count == 0) )
  panic(dom0 kernel not specified. Check bootloader configuration.);
  
 -if ( efi_enabled )
 +if ( efi_enabled(EFI_PLATFORM) )
  {
  set_pdx_range(xen_phys_start  PAGE_SHIFT,
(xen_phys_start + BOOTSTRAP_MAP_BASE)  PAGE_SHIFT);
 @@ -806,7 +806,7 @@ void

Re: [Xen-devel] [PATCH v2 13/23] efi: split out efi_get_gop()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:08PM +0200, Daniel Kiper wrote:
 ..which gets pointer to GOP device. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   59 
 ++---
  1 file changed, 36 insertions(+), 23 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 4614146..6fad230 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -630,6 +630,41 @@ static void __init efi_console_set_mode(void)
  StdOut-SetMode(StdOut, best);
  }
  
 +static EFI_GRAPHICS_OUTPUT_PROTOCOL __init *efi_get_gop(void)
 +{
 +EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
 +EFI_GRAPHICS_OUTPUT_PROTOCOL *gop;
 +EFI_HANDLE *handles;
 +EFI_STATUS status;
 +UINTN info_size, size = 0;
 +static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
 +unsigned int i;
 +
 +status = efi_bs-LocateHandle(ByProtocol, gop_guid, NULL, size, NULL);
 +if ( status == EFI_BUFFER_TOO_SMALL )
 +status = efi_bs-AllocatePool(EfiLoaderData, size, (void 
 **)handles);
 +if ( !EFI_ERROR(status) )
 +status = efi_bs-LocateHandle(ByProtocol, gop_guid, NULL, size,
 +  handles);
 +if ( EFI_ERROR(status) )
 +size = 0;
 +for ( i = 0; i  size / sizeof(*handles); ++i )
 +{
 +status = efi_bs-HandleProtocol(handles[i], gop_guid, (void 
 **)gop);
 +if ( EFI_ERROR(status) )
 +continue;
 +status = gop-QueryMode(gop, gop-Mode-Mode, info_size, 
 mode_info);
 +if ( !EFI_ERROR(status) )
 +break;
 +}
 +if ( handles )
 +efi_bs-FreePool(handles);
 +if ( EFI_ERROR(status) )
 +gop = NULL;
 +
 +return gop;
 +}
 +
  static void __init setup_efi_pci(void)
  {
  EFI_STATUS status;
 @@ -736,14 +771,12 @@ void EFIAPI __init noreturn
  efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
  {
  static EFI_GUID __initdata loaded_image_guid = LOADED_IMAGE_PROTOCOL;
 -static EFI_GUID __initdata gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
  static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
  EFI_LOADED_IMAGE *loaded_image;
  EFI_STATUS status;
  unsigned int i, argc;
  CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
  UINTN map_key, info_size, gop_mode = ~0;
 -EFI_HANDLE *handles = NULL;
  EFI_SHIM_LOCK_PROTOCOL *shim_lock;
  EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
 @@ -837,27 +870,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
 cols, rows) == EFI_SUCCESS )
  efi_arch_console_init(cols, rows);
  
 -status = efi_bs-LocateHandle(ByProtocol, gop_guid, NULL, size, 
 NULL);
 -if ( status == EFI_BUFFER_TOO_SMALL )
 -status = efi_bs-AllocatePool(EfiLoaderData, size, (void 
 **)handles);
 -if ( !EFI_ERROR(status) )
 -status = efi_bs-LocateHandle(ByProtocol, gop_guid, NULL, size,
 -  handles);
 -if ( EFI_ERROR(status) )
 -size = 0;
 -for ( i = 0; i  size / sizeof(*handles); ++i )
 -{
 -status = efi_bs-HandleProtocol(handles[i], gop_guid, (void 
 **)gop);
 -if ( EFI_ERROR(status) )
 -continue;
 -status = gop-QueryMode(gop, gop-Mode-Mode, info_size, 
 mode_info);
 -if ( !EFI_ERROR(status) )
 -break;
 -}
 -if ( handles )
 -efi_bs-FreePool(handles);
 -if ( EFI_ERROR(status) )
 -gop = NULL;
 +gop = efi_get_gop();
  
  /* Get the file system interface. */
  dir_handle = get_parent_handle(loaded_image, file_name);
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 16/23] efi: split out efi_variables()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:11PM +0200, Daniel Kiper wrote:
 ..which collects variable store parameters. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   41 -
  1 file changed, 24 insertions(+), 17 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index fd62125..177697a 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -837,6 +837,29 @@ static void __init setup_efi_pci(void)
  efi_bs-FreePool(handles);
  }
  
 +static void __init efi_variables(void)
 +{
 +EFI_STATUS status;
 +
 +status = (efi_rs-Hdr.Revision  16) = 2 ?
 + efi_rs-QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
 +   EFI_VARIABLE_BOOTSERVICE_ACCESS |
 +   EFI_VARIABLE_RUNTIME_ACCESS,
 +   efi_boot_max_var_store_size,
 +   efi_boot_remain_var_store_size,
 +   efi_boot_max_var_size) :
 + EFI_INCOMPATIBLE_VERSION;
 +if ( EFI_ERROR(status) )
 +{
 +efi_boot_max_var_store_size = 0;
 +efi_boot_remain_var_store_size = 0;
 +efi_boot_max_var_size = status;
 +PrintStr(LWarning: Could not query variable store: );
 +DisplayUint(status, 0);
 +PrintStr(newline);
 +}
 +}
 +
  static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 
 *sz)
  {
 if ( bpp  0 )
 @@ -1078,23 +1101,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  setup_efi_pci();
  
  /* Get snapshot of variable store parameters. */
 -status = (efi_rs-Hdr.Revision  16) = 2 ?
 - efi_rs-QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE |
 -   EFI_VARIABLE_BOOTSERVICE_ACCESS |
 -   EFI_VARIABLE_RUNTIME_ACCESS,
 -   efi_boot_max_var_store_size,
 -   efi_boot_remain_var_store_size,
 -   efi_boot_max_var_size) :
 - EFI_INCOMPATIBLE_VERSION;
 -if ( EFI_ERROR(status) )
 -{
 -efi_boot_max_var_store_size = 0;
 -efi_boot_remain_var_store_size = 0;
 -efi_boot_max_var_size = status;
 -PrintStr(LWarning: Could not query variable store: );
 -DisplayUint(status, 0);
 -PrintStr(newline);
 -}
 +efi_variables();
  
  efi_arch_memory_setup();
  
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 20/23] x86: add multiboot2 protocol support for EFI platforms

[Konrad Rzeszutek Wilk]

/include/xen/efi.h b/xen/include/xen/efi.h
 index 318bbec..6b952df 100644
 --- a/xen/include/xen/efi.h
 +++ b/xen/include/xen/efi.h
 @@ -9,6 +9,7 @@
  #define EFI_INVALID_TABLE_ADDR (~0UL)
  
  #define EFI_PLATFORM 0
 +#define EFI_LOADER   1
  
  /* Add fields here only if they need to be referenced from non-EFI code. */
  struct efi {


With the changes above:

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:05PM +0200, Daniel Kiper wrote:
 Build xen.gz with EFI code. We need this to support multiboot2
 protocol on EFI platforms.
 
 If we wish to load not ELF file using multiboot (v1) or multiboot2 then
 it must contain linear (or flat) representation of code and data.
 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). In theory there is a chance that we could build
 proper PE file using current build system. However, it means that
 xen.efi further diverge from xen ELF file (in terms of contents and
 build method). ELF have 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.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com
 ---
 v2 - suggestions/fixes:
- build EFI code only if it is supported in a given build environment
  (suggested by Jan Beulich).
 ---
  xen/arch/x86/Makefile |   13 +
  xen/arch/x86/efi/Makefile |   16 +---
  xen/arch/x86/mm.c |3 ++-
  xen/common/efi/runtime.c  |6 ++
  4 files changed, 22 insertions(+), 16 deletions(-)
 
 diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
 index 5f24951..0335445 100644
 --- a/xen/arch/x86/Makefile
 +++ b/xen/arch/x86/Makefile
 @@ -80,7 +80,7 @@ ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
 $(BASEDIR)/arch/x86/efi/built_in
  
  ifeq ($(lto),y)
  # Gather all LTO objects together
 -prelink_lto.o: $(ALL_OBJS)
 +prelink_lto.o: $(ALL_OBJS) efi/relocs-dummy.o
   $(LD_LTO) -r -o $@ $^
  
  prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
 @@ -90,14 +90,14 @@ prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
  prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
 prelink_lto.o
   $(LD) $(LDFLAGS) -r -o $@ $^
  
 -prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
 prelink-efi_lto.o efi/boot.init.o
 +prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
 prelink-efi_lto.o
   $(guard) $(LD) $(LDFLAGS) -r -o $@ $^
  else
 -prelink.o: $(ALL_OBJS)
 +prelink.o: $(ALL_OBJS) efi/relocs-dummy.o
   $(LD) $(LDFLAGS) -r -o $@ $^
  
 -prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
 - $(guard) $(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
 +prelink-efi.o: $(ALL_OBJS)
 + $(guard) $(LD) $(LDFLAGS) -r -o $@ $^
  endif
  
  $(BASEDIR)/common/symbols-dummy.o:
 @@ -146,9 +146,6 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o 
 $(BASEDIR)/common/symbol
   if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
   rm -f $(@D)/.$(@F).[0-9]*
  
 -efi/boot.init.o efi/runtime.o efi/compat.o: 
 $(BASEDIR)/arch/x86/efi/built_in.o
 -efi/boot.init.o efi/runtime.o efi/compat.o: ;
 -
  asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
   $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $
  
 diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
 index 1daa7ac..b1e8883 100644
 --- a/xen/arch/x86/efi/Makefile
 +++ b/xen/arch/x86/efi/Makefile
 @@ -1,14 +1,16 @@
  CFLAGS += -fshort-wchar
  
 -obj-y += stub.o
 -
 -create = test -e $(1) || touch -t 19990101 $(1)
 -
  efi := $(filter y,$(x86_64)$(shell rm -f disabled))
  efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
 check.c 2disabled  echo y))
  efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi 
 check.o 2disabled  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
 +extra-y += relocs-dummy.o
  
 -stub.o: $(extra-y)
 +ifeq ($(efi),y)
 +obj-y += boot.init.o
 +obj-y += compat.o
 +obj-y += runtime.o
 +else
 +obj-y += stub.o
 +endif

That makefile magic I skipped over, but the C code below looks good, so

Half-Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com


 diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
 index 342414f..cef2eb6 100644
 --- a/xen/arch/x86/mm.c
 +++ b/xen/arch/x86/mm.c
 @@ -344,7 +344,8 @@ void __init arch_init_memory(void)
  
  subarch_init_memory();
  
 -efi_init_memory();
 +if ( efi_enabled(EFI_PLATFORM) )
 +efi_init_memory();
  
  mem_sharing_init();
  
 diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
 index aa064e7..3eb21c1 100644
 --- a/xen/common/efi/runtime.c
 +++ b/xen/common/efi/runtime.c
 @@ -167,6 +167,9 @@ int efi_get_info(uint32_t idx, union xenpf_efi_info *info)
  {
  unsigned int i, n;
  
 +if ( !efi_enabled(EFI_PLATFORM) )
 +return -EOPNOTSUPP;
 +
  switch ( idx

Re: [Xen-devel] [PATCH v2 14/23] efi: split out efi_find_gop_mode()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:09PM +0200, Daniel Kiper wrote:
 ..which finds suitable GOP mode. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   94 
 -
  1 file changed, 54 insertions(+), 40 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 6fad230..8d16470 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -665,6 +665,58 @@ static EFI_GRAPHICS_OUTPUT_PROTOCOL __init 
 *efi_get_gop(void)
  return gop;
  }
  
 +static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
 +  UINTN cols, UINTN rows, UINTN depth)
 +{
 +EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
 +EFI_STATUS status;
 +UINTN gop_mode = ~0, info_size, size;
 +unsigned int i;
 +
 +if ( !gop )
 +return gop_mode;
 +
 +for ( i = size = 0; i  gop-Mode-MaxMode; ++i )
 +{
 +unsigned int bpp = 0;
 +
 +status = gop-QueryMode(gop, i, info_size, mode_info);
 +if ( EFI_ERROR(status) )
 +continue;
 +switch ( mode_info-PixelFormat )
 +{
 +case PixelBitMask:
 +bpp = hweight32(mode_info-PixelInformation.RedMask |
 +mode_info-PixelInformation.GreenMask |
 +mode_info-PixelInformation.BlueMask);
 +break;
 +case PixelRedGreenBlueReserved8BitPerColor:
 +case PixelBlueGreenRedReserved8BitPerColor:
 +bpp = 24;
 +break;
 +default:
 +continue;
 +}
 +if ( cols == mode_info-HorizontalResolution 
 + rows == mode_info-VerticalResolution 
 + (!depth || bpp == depth) )
 +{
 +gop_mode = i;
 +break;
 +}
 +if ( !cols  !rows 
 + mode_info-HorizontalResolution *
 + mode_info-VerticalResolution  size )
 +{
 +size = mode_info-HorizontalResolution *
 +   mode_info-VerticalResolution;
 +gop_mode = i;
 +}
 +}
 +
 +return gop_mode;
 +}
 +
  static void __init setup_efi_pci(void)
  {
  EFI_STATUS status;
 @@ -978,46 +1030,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  
  dir_handle-Close(dir_handle);
  
 -if ( gop  !base_video )
 -{
 -for ( i = size = 0; i  gop-Mode-MaxMode; ++i )
 -{
 -unsigned int bpp = 0;
 -
 -status = gop-QueryMode(gop, i, info_size, mode_info);
 -if ( EFI_ERROR(status) )
 -continue;
 -switch ( mode_info-PixelFormat )
 -{
 -case PixelBitMask:
 -bpp = hweight32(mode_info-PixelInformation.RedMask |
 -mode_info-PixelInformation.GreenMask |
 -mode_info-PixelInformation.BlueMask);
 -break;
 -case PixelRedGreenBlueReserved8BitPerColor:
 -case PixelBlueGreenRedReserved8BitPerColor:
 -bpp = 24;
 -break;
 -default:
 -continue;
 -}
 -if ( cols == mode_info-HorizontalResolution 
 - rows == mode_info-VerticalResolution 
 - (!depth || bpp == depth) )
 -{
 -gop_mode = i;
 -break;
 -}
 -if ( !cols  !rows 
 - mode_info-HorizontalResolution *
 - mode_info-VerticalResolution  size )
 -{
 -size = mode_info-HorizontalResolution *
 -   mode_info-VerticalResolution;
 -gop_mode = i;
 -}
 -}
 -}
 +if ( !base_video )
 +gop_mode = efi_find_gop_mode(gop, cols, rows, depth);
  }
  
  efi_arch_edd();
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 17/23] efi: split out efi_set_gop_mode()

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:12PM +0200, Daniel Kiper wrote:
 ..which sets chosen GOP mode. We want to re-use this
 code to support multiboot2 protocol on EFI platforms.
 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
 v2 - suggestions/fixes:
- improve commit message
  (suggested by Jan Beulich).
 ---
  xen/common/efi/boot.c |   33 -
  1 file changed, 20 insertions(+), 13 deletions(-)
 
 diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
 index 177697a..04b9c7e 100644
 --- a/xen/common/efi/boot.c
 +++ b/xen/common/efi/boot.c
 @@ -860,6 +860,25 @@ static void __init efi_variables(void)
  }
  }
  
 +static void __init efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
 gop_mode)
 +{
 +EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
 +EFI_STATUS status;
 +UINTN info_size;
 +
 +if ( !gop )
 +return;
 +
 +/* Set graphics mode. */
 +if ( gop_mode  gop-Mode-MaxMode  gop_mode != gop-Mode-Mode )
 +gop-SetMode(gop, gop_mode);
 +
 +/* Get graphics and frame buffer info. */
 +status = gop-QueryMode(gop, gop-Mode-Mode, info_size, mode_info);
 +if ( !EFI_ERROR(status) )
 +efi_arch_video_init(gop, info_size, mode_info);
 +}
 +
  static int __init __maybe_unused set_color(u32 mask, int bpp, u8 *pos, u8 
 *sz)
  {
 if ( bpp  0 )
 @@ -887,7 +906,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  UINTN map_key, info_size, gop_mode = ~0;
  EFI_SHIM_LOCK_PROTOCOL *shim_lock;
  EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
 -EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
  union string section = { NULL }, name;
  bool_t base_video = 0, retry;
  char *option_str;
 @@ -1105,18 +1123,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
 *SystemTable)
  
  efi_arch_memory_setup();
  
 -if ( gop )
 -{
 -
 -/* Set graphics mode. */
 -if ( gop_mode  gop-Mode-MaxMode  gop_mode != gop-Mode-Mode )
 -gop-SetMode(gop, gop_mode);
 -
 -/* Get graphics and frame buffer info. */
 -status = gop-QueryMode(gop, gop-Mode-Mode, info_size, 
 mode_info);
 -if ( !EFI_ERROR(status) )
 -efi_arch_video_init(gop, info_size, mode_info);
 -}
 +efi_set_gop_mode(gop, gop_mode);
  
  info_size = 0;
  efi_bs-GetMemoryMap(info_size, NULL, map_key,
 -- 
 1.7.10.4
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 19/23] x86/efi: create new early memory allocator

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:14PM +0200, Daniel Kiper wrote:
 There is a problem with place_string() which is used as early memory
 allocator. It gets memory chunks starting from start symbol and
 going down. Sadly this does not work when Xen is loaded using multiboot2
 protocol because start lives on 1 MiB address. So, I tried to use

s/So, I tried to use/With/
 mem_lower address calculated by GRUB2. However, it works only on some

s/GRUB2. However, //

 machines. There are machines in the wild (e.g. Dell PowerEdge R820)
 which uses first ~640 KiB for boot services code or data... :-(((
 
 In case of multiboot2 protocol we need that place_string() only allocate

s/only/to only/
 memory chunk for EFI memory map. However, I think that it should be fixed
 instead of making another function used just in one case. I thought about
 two solutions.

s/I think ...two solutions/There are two solutions:/

 
 1) We could use native EFI allocation functions (e.g. AllocatePool()
or AllocatePages()) to get memory chunk. However, later (somewhere
in __start_xen()) we must copy its contents to safe place or reserve
this in e820 memory map and map it in Xen virtual address space.
In later case we must also care about conflicts with e.g. crash
kernel regions which could be quite difficult.
 
 2) We may allocate memory area statically somewhere in Xen code which
could be used as memory pool for early dynamic allocations. Looks
quite simple. Additionally, it would not depend on EFI at all and
could be used on legacy BIOS platforms if we need it. However, we
must carefully choose size of this pool. We do not want increase
Xen binary size too much and waste too much memory but also we must fit

Aren't we gziping the binary? In which you do not waste that much disk space.

at least memory map on x86 EFI platforms. As I saw on small machine,

s/at least memory map on/on small memory/

s/As I saw on small machine/For example on/

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.

s/entries. Every entry on .. is/wherein every entry is/

So, it means that we need more than 8 KiB for EFI memory map only.

s/So, it means that we need more than/Brings it up to/

Additionally, if we want to use this memory pool for Xen and modules
command line storage (it would be used when xen.efi is executed as EFI
application) then we should add, I think, about 1 KiB. In this case,

s/,I think, //

to be on safe side, we should assume at least 64 KiB pool for early
memory allocations, which is about 4 times of our earlier calculations.
However, during discussion on Xen-devel Jan Beulich suggested that
just in case we should use 1 MiB memory pool like it was in original
place_string() implementation. So, let's use 1 MiB as it was proposed.

s/If we think that we should not/To not/

If we think that we should not waste unallocated memory in the pool
on running system then we can mark this region as __initdata and move
all required data to dynamically allocated places somewhere in 
 __start_xen().
 
 Now solution #2 is implemented but maybe we should consider #1 one day.

s/Now ../This patch implements #2 solution./

 
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com with the
adjustments mentioned.
 ---
  xen/arch/x86/efi/efi-boot.h |   38 ++
  xen/arch/x86/setup.c|3 +--
  2 files changed, 31 insertions(+), 10 deletions(-)
 
 diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
 index 2dd69f6..3d25c48 100644
 --- a/xen/arch/x86/efi/efi-boot.h
 +++ b/xen/arch/x86/efi/efi-boot.h
 @@ -103,9 +103,36 @@ static void __init relocate_trampoline(unsigned long 
 phys)
  *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys  4;
  }
  
 +#define EBMALLOC_SIZEMB(1)
 +
 +static char __initdata ebmalloc_mem[EBMALLOC_SIZE];
 +static char __initdata *ebmalloc_free = NULL;
 +
 +/* EFI boot allocator. */
 +static void __init *ebmalloc(size_t size)
 +{
 +void *ptr;
 +
 +/*
 + * Init ebmalloc_free on runtime. Static initialization
 + * will not work because it puts virtual address there.

And why is that bad?

 + */
 +if ( ebmalloc_free == NULL )
 +ebmalloc_free = ebmalloc_mem;
 +
 +ptr = ebmalloc_free;
 +
 +ebmalloc_free += size;
 +
 +if ( ebmalloc_free - ebmalloc_mem  sizeof(ebmalloc_mem) )
 +blexit(LOut of static memory\r\n);
 +
 +return ptr;
 +}
 +
  static void __init place_string(u32 *addr, const char *s)
  {
 -static char *__initdata alloc = start;
 +char *alloc = NULL;
  
  if ( s  *s )
  {
 @@ -113,7 +140,7 @@ static void __init place_string(u32 *addr, const char *s)
  const char *old = (char *)(long)*addr;
  size_t len2 = *addr ? strlen(old) + 1

Re: [Xen-devel] [PATCH v2 21/23] x86/boot: implement early command line parser in C

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:29:16PM +0200, Daniel Kiper 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 and much easier
 to maintain.
 
 Suggested-by: Andrew Cooper andrew.coop...@citrix.com
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

I did not look at the str* functions that were added in but just
at how the parameters parsing was done. Also at the assembler code and
with that

Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
.. snip..
 diff --git a/xen/arch/x86/boot/cmdline.c b/xen/arch/x86/boot/cmdline.c
 new file mode 100644
 index 000..5ea50a4
 --- /dev/null
 +++ b/xen/arch/x86/boot/cmdline.c
 @@ -0,0 +1,396 @@
 +/*
 + * Copyright (c) 2015 Oracle Co.


Oracle Corporation.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 01/23] x86/boot: remove unneeded instruction

[Konrad Rzeszutek Wilk]

On Mon, Jul 20, 2015 at 04:28:56PM +0200, Daniel Kiper wrote:
 Signed-off-by: Daniel Kiper daniel.ki...@oracle.com

Don't you use it in:

/* Switch to low-memory stack.  */  
193 mov sym_phys(trampoline_phys),%edi  

194 lea 0x1(%edi),%esp  

195 lea trampoline_boot_cpu_entry-trampoline_start(%edi),%eax   
?

 ---
  xen/arch/x86/boot/head.S |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
 index cfd59dc..f63b349 100644
 --- a/xen/arch/x86/boot/head.S
 +++ b/xen/arch/x86/boot/head.S
 @@ -169,7 +169,6 @@ __start:
  /* Apply relocations to bootstrap trampoline. */
  mov sym_phys(trampoline_phys),%edx
  mov $sym_phys(__trampoline_rel_start),%edi
 -mov %edx,sym_phys(trampoline_phys)
  1:
  mov (%edi),%eax
  add %edx,(%edi,%eax)
 -- 
 1.7.10.4
 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] [PATCH v2 2/3] util/grub.d/20_linux_xen.in: Add arm64 support

[Konrad Rzeszutek Wilk]

On Tue, Jul 14, 2015 at 10:41:28AM +0100, Ian Campbell wrote:
 On Tue, 2015-07-14 at 06:53 +0300, Andrei Borzenkov wrote:
   +if [ x$machine != xaarch64 ]; then
   + multiboot_cmd=multiboot
   + module_cmd=module

And we should use the grub-file --is-multiboot2 to figure out if the
Xen binary can also do that - and use multiboot2 protocol.

But that patch I can cobble after this one is done.

   +else
   + multiboot_cmd=xen_hypervisor
   + module_cmd=xen_module
   +fi
   +
  
  Strictly speaking, this is boot-time decision. As mentioned by
  Vladimir, better would be to provide alias xen_hypervisor and
  xen_module in multiboot for platforms supporting Xen (is MIPS really
  supported?) and use it consistently.
 
 I had been thinking of this the other way around, e.g. on platforms
 which support Xen but not multiboot1 multiboot would be added as an
 alias for xen_hypervisor.
 
 However so long as grub-mkconfig (via 20_linux_xen) work for everyone
 and that peoples existing hand-crafted x86/multiboot/Xen grub.cfg's
 continue to work then I think having the alias go either way would be
 fine.
 
 BTW I had been going to suggest a function at the grub.cfg level which
 dispatched to the correct command, but I suppose an actual alias is
 better.
 
 Ian.
 
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Is: grub2-mkconfig detecting ELF files the multiboot2 header and using proper module. Was:Re: [PATCH 0/5] multiboot2: Enable EFI boot services usage in loaded images

[Konrad Rzeszutek Wilk]

  and using some of that logic to inspect the Xen to find
  the MB2 header?
 
 See grub-file tool. Possibly it's still only in next branch

I see it. Thank you.

I also see 'faf4a65e1e1ce1d822d251c1e4b53d96ec7faec5'
Revert grub-file usage in grub-mkconfig.

but not much of an explanation? What didn't work?

Thanks!
  But I am having a hard time finding them? Vladimir do you remember
  where they might be?
 
  Thank you!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Is: grub2-mkconfig detecting ELF files the multiboot2 header and using proper module. Was:Re: [PATCH 0/5] multiboot2: Enable EFI boot services usage in loaded images

[Konrad Rzeszutek Wilk]

On Mon, Feb 09, 2015 at 06:55:05PM +0100, Daniel Kiper wrote:
 Hi all,
 
 On Fri, Jan 30, 2015 at 06:59:23PM +0100, Daniel Kiper wrote:
  Hi,
 
  This patch series enable EFI boot services usage
  in loaded images by multiboot2 protocol.
 
 Guys, do you have any comments on this patch series?
 Should I fix something? Could you apply them to GRUB2 tree?

Hey,

Follow up part of this is to make 20_linux_xen.in be able to detect
whether Xen.gz can be loaded using multiboot2.

I was thinking to piggy-back on the patches which dropped
the check on CONFIG_XEN_DOM0 in the Linux kernel config file
as (I think so) it was inspecting the ELF of the Linux kernel
and determining if it has .note.Xen (see
http://xenbits.xen.org/docs/4.3-testing/misc/dump-core-format.txt or
http://wiki.xen.org/wiki/X86_Paravirtualised_Memory_Management#Start_Of_Day)
and using some of that logic to inspect the Xen to find
the MB2 header?

But I am having a hard time finding them? Vladimir do you remember
where they might be?

Thank you!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen

[Konrad Rzeszutek Wilk]

On Sun, Nov 10, 2013 at 09:40:29PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
 On 15.07.2013 20:00, Konrad Rzeszutek Wilk wrote:
  Hey,
  
  There is a discussion on the linux-kernel mailing list in which the
  Linus states that if you depend on any config file, you're broken
  by definition (https://lkml.org/lkml/2013/7/15/368).
  
 Please try my grub_file branch:
 http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/grub_file
 It should do what you want.
 

Oddly I get this after I installed it.

/sbin/grub-probe: error: failed to get canonical path of `'.

And I kind of fixed it by removing the 'set -e' at the start
of the file.

After that, and with me removing the /boot/config-3.12.0 file
it generates an proper entry in grub.cfg for the Xen payload!
Yeey!

The other thing I saw was that the 'root' option for Linux
ended up being 'root=' instead of the 'root=UUID=blabla'.

See here:

if [ x$grub_platform != xxen \(  x$grub_cpu = xi386 -o x$grub_cpu = 
xx86_64 -o x$grub_platform = x \) ]; then
menuentry 'Fedora GNU/Linux, with Xen hypervisor' --class fedora --class 
gnu-linux --class gnu --class os --class xen $menuentry_id_option 
'xen-gnulinux-simple-' {
insmod part_msdos 
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  
760e0266-1a60-4621-b332-0788cf687e33
else
  search --no-floppy --fs-uuid --set=root 
760e0266-1a60-4621-b332-0788cf687e33
fi
echo'Loading Xen xen ...'
if [ $grub_platform = pc -o $grub_platform =  ]; then
xen_rm_opts=
else
xen_rm_opts=no-real-mode edd=off
fi
multiboot   /xen.gz placeholder guest_loglvl=all com1=115200,8n1 
console=com1,vga loglvl=all 
iommu=no-amd-iommu-perdev-intremap,verbose,debug,no-intremap  ${xen_rm_opts}
echo'Loading Linux 3.12.0 ...'
module  /vmlinuz-3.12.0 placeholder root= ro rd.md=0 rd.lvm=0 rd.dm=0 
rd.luks=0  loglevel=8 radeon.modeset=0 xen-pciback.hide=(05:00.*) console=hvc0 
echo'Loading initial ramdisk ...'
module  /initramfs-3.12.0.img
}

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] remove dependency on /boot/config-* in grub.d/20_linux_xen

[Konrad Rzeszutek Wilk]

On Sun, Nov 10, 2013 at 09:40:29PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
 On 15.07.2013 20:00, Konrad Rzeszutek Wilk wrote:
  Hey,
  
  There is a discussion on the linux-kernel mailing list in which the
  Linus states that if you depend on any config file, you're broken
  by definition (https://lkml.org/lkml/2013/7/15/368).
  
 Please try my grub_file branch:
 http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/grub_file
 It should do what you want.

Will do this week! Thank you!
 



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Xen-devel] GRUB2 XEN PV port is able to boot linux

[Konrad Rzeszutek Wilk]

On Tue, Nov 05, 2013 at 04:40:29AM +0100, Vladimir '??-coder/phcoder' 
Serbinenko wrote:
 On 05.11.2013 04:39, Vladimir '??-coder/phcoder' Serbinenko wrote:
  For now it's 64-bit only but it works. I've also tested with netbsd and
  GNU mach. All of them work as well as when launched directly from
  hypervisor.
 Forgot the most important thing: it's available under
 http://git.savannah.gnu.org/cgit/grub.git/log/?h=phcoder/newports/xen
 
 

Fantastic!

I didn't look in details - but will the build of grub2 require
any specific headers, etc to build this binary?

Thanks!


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


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: EFI and multiboot2 devlopment work for Xen

[Konrad Rzeszutek Wilk]

On Tue, Oct 22, 2013 at 10:54:44AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
 On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
  Mail is big, I think I got your essential points but I didn't read it whole.
  On 21.10.2013 14:57, Daniel Kiper wrote:
  Hi,
 
  During work on multiboot2 protocol support for Xen it was discovered
  that memory map passed via relevant tag could not represent wide range
  of memory types available on EFI platforms. Additionally, GRUB2
  implementation calls ExitBootServices() on them just before jumping
  into loaded image. In this situation loaded system could not clearly
  identify reserved memory regions, EFI runtime services regions and others.
 
  Will a multiboot2 tag with whole EFI memory map solve your problem?
 I added such a tag in documentation and wrote a patch for it (attached).
 Awaiting for someone to test it to commit

Great! I think from Xen perspective we first need to have Xen be able
to understand multiboot2 - that is something Daniel had been working on.
I will let Daniel talk more about it.

Seth, would you have any time to test the patch against Solaris to
make sure it works?

Thanks!
 




=== modified file 'grub-core/loader/i386/multiboot_mbi.c'
--- grub-core/loader/i386/multiboot_mbi.c   2013-10-14 14:33:44 +
+++ grub-core/loader/i386/multiboot_mbi.c   2013-10-22 06:57:45 +
@@ -36,6 +36,10 @@
 #include grub/net.h
 #include grub/i18n.h
 
+#ifdef GRUB_MACHINE_EFI
+#include grub/efi/efi.h
+#endif
+
 /* The bits in the required part of flags field we don't support.  */
 #define UNSUPPORTED_FLAGS  0xfff8
 
@@ -579,6 +583,12 @@
   ptrdest += sizeof (struct grub_vbe_mode_info_block);
 #endif
 
+#ifdef GRUB_MACHINE_EFI
+  err = grub_efi_finish_boot_services (NULL, NULL, NULL, NULL, NULL);
+  if (err)
+return err;
+#endif
+
   return GRUB_ERR_NONE;
 }
 

=== modified file 'grub-core/loader/multiboot.c'
--- grub-core/loader/multiboot.c2013-09-23 11:35:33 +
+++ grub-core/loader/multiboot.c2013-10-22 06:51:30 +
@@ -131,12 +131,6 @@
   if (err)
 return err;
 
-#ifdef GRUB_MACHINE_EFI
-  err = grub_efi_finish_boot_services (NULL, NULL, NULL, NULL, NULL);
-  if (err)
-return err;
-#endif
-
 #if defined (__i386__) || defined (__x86_64__)
   grub_relocator32_boot (grub_multiboot_relocator, state, 0);
 #else

=== modified file 'grub-core/loader/multiboot_mbi2.c'
--- grub-core/loader/multiboot_mbi2.c   2013-10-14 14:33:44 +
+++ grub-core/loader/multiboot_mbi2.c   2013-10-22 06:57:58 +
@@ -295,9 +295,55 @@
 #endif
 }
 
+#ifdef GRUB_MACHINE_EFI
+
+static grub_efi_uintn_t efi_mmap_size = 0;
+
+/* Find the optimal number of pages for the memory map. Is it better to
+   move this code to efi/mm.c?  */
+static void
+find_efi_mmap_size (void)
+{
+  efi_mmap_size = (1  12);
+  while (1)
+{
+  int ret;
+  grub_efi_memory_descriptor_t *mmap;
+  grub_efi_uintn_t desc_size;
+  grub_efi_uintn_t cur_mmap_size = efi_mmap_size;
+
+  mmap = grub_malloc (cur_mmap_size);
+  if (! mmap)
+   return;
+
+  ret = grub_efi_get_memory_map (cur_mmap_size, mmap, 0, desc_size, 0);
+  grub_free (mmap);
+
+  if (ret  0)
+   return;
+  else if (ret  0)
+   break;
+
+  if (efi_mmap_size  cur_mmap_size)
+   efi_mmap_size = cur_mmap_size;
+  efi_mmap_size += (1  12);
+}
+
+  /* Increase the size a bit for safety, because GRUB allocates more on
+ later, and EFI itself may allocate more.  */
+  efi_mmap_size += (3  12);
+
+  efi_mmap_size = ALIGN_UP (efi_mmap_size, 4096);
+}
+#endif
+
 static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
+#ifdef GRUB_MACHINE_EFI
+  if (!efi_mmap_size)
+find_efi_mmap_size ();
+#endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
 + (sizeof (struct multiboot_tag_string)
+ ALIGN_UP (cmdline_size, MULTIBOOT_TAG_ALIGN))
@@ -318,6 +364,10 @@
 + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
 + acpiv2_size ()
+#ifdef GRUB_MACHINE_EFI
++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
+#endif
 + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
 + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
 }
@@ -760,6 +810,28 @@
   }
 #endif
 
+#ifdef GRUB_MACHINE_EFI
+  {
+struct multiboot_tag_efi_mmap *tag = (struct multiboot_tag_efi_mmap *) 
ptrorig;
+grub_efi_uintn_t efi_desc_size;
+grub_efi_uint32_t efi_desc_version;
+
+tag-type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+tag-size = sizeof (*tag) + efi_mmap_size;
+
+err = grub_efi_finish_boot_services (efi_mmap_size, tag-efi_mmap, NULL,
+efi_desc_size, efi_desc_version);
+if (err)
+  return err;
+tag-descr_size = efi_desc_size;
+tag-descr_vers = efi_desc_version;
+

Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

[Konrad Rzeszutek Wilk]

On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
 On Tue, 2013-10-22 at 12:26 -0400, Konrad Rzeszutek Wilk wrote:
  It can (at least in Linux). There are two entry points in the Linux kernel
  and - one when it is launched from 'linuxefi' (See efi_stub_entry in 
  arch/x86/boot/compressed/head_64.S), the other when it is launched
  from an EFI shell - see efi_pe_entry in arch/x86/boot/compressed/head_64.S.
 
 
 Yes, it seems I was confused and spreading misinformation. Sorry!
 
 Matthew explained this stuff to me yesterday, let me see if I can
 regurgitate it. Hopefully Matthew can crrect the inevitable mistakes...
 
 A kernel binary built with EFI stub support has three entry points:
 
   * The traditional real mode zImage entry point
   * The standard PE/COFF entry point
   * A Linux EFI PE/COFF entry point
 
 I think we can safely ignore the first of these for the purposes of this
 conversation. I'm also going to ignore SB initially and cover it
 separately at the end.
 
 The second (standard PE/COFF entry point) can be launched using the UEFI
 chainloader call. AIUI this should work with xen.efi today. There are
 some limitations however, firstly there is no way to pass additional
 blobs and so the launched image must load e.g. dom0 and initrd itself,
 which Linux does by processing the initrd= option in the command line
 and using UEFI functionality to load the blobs from disk. Xen does by
 reading its own config file and loading dom0 + initrd based on that. I
 assume this means that chainload doesn't call ExitBootServices (anyone
 can confirm?). Another limitation of this is that the UEFI functionality

Confirmed.

 to load stuff from disk can only read from FAT partitions.  It's not
 clear to me if this mechanism limits only the loading of additional
 blobs from FAT or if that applies to the kernel image itself. In reality
 the blob and the kernel are usually stored in the same directory anyhow.
 
 Is there a second method which can load standard PE/COFF images i.e.
 some sort of boot a kernel method which calls ExitBootServices etc?
 Even if this exists I don't think we can/want to use it.

None that I can find in GRUB2 - either upstream or Fedora's version.

 
 The third (Linux EFI PE/COFF entry) is launched with the efilinux
 patch to grub. This does not call ExitBootServices and also passes an
 additional struct to the kernel which contains mostly (exactly? == is
 the same struct) the same stuff as the traditional 16-bit entry point
 would construct and pass to the 32-bit kernel. The EFI stub can also use
 UEFI calls to get most (all?) of the same info. There was some related
 madness about how the framebuffer is detected. Unlike the chainload
 mechanism efilinux does not expect or provide PE/COFF relocation. The
 kernel is PIC on entry so no relocations are actually needed. In theory
 the Linux EFI stub could instead have included a NULL relocation table
 but doesn't. (I expect Xen is in the same boat WRT relocations). I think
 this method also provides a mechanism to provide a blob (AKA the initrd)
 to the kernel, which means it can be loaded from any filesystem which
 grub understands (not just FAT). There is only one which is a not
 sufficient for Xen.

Correct. Especially as we might have many binary blobs - microcode blob,
XSM blob, whoknowswhatblob, etc.
 
 From a SB point of view the major difference between chainload and
 linuxefi is that chainload can only validate signatures against the UEFI
 core key db (maintained by UEFI) while linuxefi can also use keys from
 MOK db (Machine Operator Key, which is a second DB provided and
 maintained by shim). Michael was saying elsewhere in this thread that
 SuSE at least have a patch which allow the chainload mechanism to use
 MOK as well.
 
 I hope that is an accurate braindump of what Matthew explained to me
 yesterday, mistakes are naturally all mine ;-)
 
 Am I correct that xen.efi today can be loaded from grub today using the
 chainload command? Whereupon it will parse the xen.cfg and load the dom0
 kernel and load things from FAT etc and everything just works. IOW
 UEFI - chainload(Xen)
 and
 UEFI - chainload(grub) - chainload(Xen)
 work equivalently from the POV of Xen?

Yes. However it does require the user to know the magic values in the Xen
configuration file and setup the chainload stanze correctly. That means
if a user wishes to modify some of the bootup options they have to modify
the Xen configuration file. No runtime changes.

From a distro standpoint the FAT part is painfull - as the common mechanism
for the /boot directory is to have it in ext2/ext3. But I presume you can
have _two_ boot partitions with GPT - one FAT and one ext2 and the tool
(dracut?) can push the images/config changes in both partitions.

Hence the idea of expanding GRUB2 to have an evercompassing multiboot2
protocol that will carry all the EFI bits  and allow multiple
seperate payloads will require:

 - not make

Re: EFI and multiboot2 devlopment work for Xen

[Konrad Rzeszutek Wilk]

On Tue, Oct 22, 2013 at 02:53:05PM +0100, Ian Campbell wrote:
 On Tue, 2013-10-22 at 09:42 -0400, Konrad Rzeszutek Wilk wrote:
 
  Looking at the Fedora GRUB2 source, the 'struct linux_kernel_header' is 
  defined
  in the linux/Documentation/x86/boot.txt and hpa is pretty strict
  about making it backwards compatible. It also seems to support Xen!
  
  (Interestingly enough we do have this structure in the code: see
  setup_header in arch/x86/bzimage.c)
 
 There will be another usage in tools/libxc/...bzimage too

Right.
 
 FWIW I think we only use this stuff for the magic number/version and the
 payload_offset/length fields, which we do in order to extract the
 payload (ELF file) for booting dom0 and domU. It's not AFAIK used for
 booting Xen itself or lets say, that's not why I added it ;-)).

Right. I just meant that we have some of the code in the hypervisor
so using it to pass the EFI payload that way could be possible. But
then I realized it is pointless as we boot using the PV mechanism
which gets the EFI payload via hypercalls. So many ways to get this.

 
  Which in the GRUB2 is being constructed by parsing the EFI
  data structures. But Linux concentrates on the EFI parts and mostly
  ignores the rest. So this is more about passing those EFI values
  downstream.
 
 I wonder why Linux can't make the EFI calls to fetch them itself?

I believe it can if it is launched that way. Here is what I saw in the
Linux kernel:
/*  
 * Determine if we were loaded by an EFI loader.  If so, then we have also been 
 * passed the efi memmap, systab, etc., so we should use these data structures  
 * for initialization.  Note, the efi init code path is determined by the   

 * global efi_enabled. This allows the same kernel image to be used on existing 
 * systems (with a traditional BIOS) as well as on EFI systems. 
 */ 

Looking at arch/x86/boot/header.S in Linux I see some PE header and this
commit explains at lot:

commit 291f36325f9f252bd76ef5f603995f37e453fc60
Author: Matt Fleming matt.flem...@intel.com
Date:   Mon Dec 12 21:27:52 2011 +

x86, efi: EFI boot stub support

There is currently a large divide between kernel development and the
development of EFI boot loaders. The idea behind this patch is to give
the kernel developers full control over the EFI boot process. As
H. Peter Anvin put it,

The 'kernel carries its own stub' approach been very successful in
dealing with BIOS, and would make a lot of sense to me for EFI as
well.

This patch introduces an EFI boot stub that allows an x86 bzImage to
be loaded and executed by EFI firmware. The bzImage appears to the
firmware as an EFI application. Luckily there are enough free bits
within the bzImage header so that it can masquerade as an EFI
application, thereby coercing the EFI firmware into loading it and
jumping to its entry point. The beauty of this masquerading approach
is that both BIOS and EFI boot loaders can still load and run the same
bzImage, thereby allowing a single kernel image to work in any boot
environment.

The EFI boot stub supports multiple initrds, but they must exist on
the same partition as the bzImage. Command-line arguments for the
kernel can be appended after the bzImage name when run from the EFI
shell, e.g.

Shell bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img


So it can be booted the same way as xen.efi. But my understanding is
that folks prefer a bootloader instead of loading the bzImage in an
NVRAM of a platform with pre-set parameters. Hence that mechanism
is not used by the majority of users.

Instead the majority of users would like to use a bootloader, like
GRUB2. And there are certain restrictions - if you launch from it
an PE/COFF application GRUB2 will call ExitBootServices. But if
you launch the Linux image (so using the linuxefi), it WILL NOT
call ExitBootServices.

But I say that (about ExitBootServices) - and I can't find it in
the GRUB2 code, so perhaps I am mistaken.

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel