On 14.03.2024 15:24, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
>> On 14.03.2024 10:30, Ross Lagerwall wrote:
>>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>>>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>>>>
On 14.03.2024 10:30, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>>
>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>> In addition to the existing address and ELF load types, specify a new
>>> optional PE binary load type. This ne
On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF load types, specify a new
> optional PE binary load type. This new type is a useful addition since
> PE binaries can be signed and verified (i.e. used with Secure Boot).
And the consideration to have ELF signa
On 01.04.2021 21:43, Andrew Cooper wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
>>>> And the obvious next question: is my EVE usecase esoteric eno
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecase esoteric enough that
> I should just go ahead and do a custom GRUB patch or is there a more
> general interest in this?
Not sure if it ought to be a grub patch - the issue could as well
be dealt with in
>>> On 11.01.16 at 15:58, wrote:
> On 11.01.2016 15:32, Jan Beulich wrote:
>>>>> On 11.01.16 at 15:06, wrote:
>>> On 13.11.2015 10:50, Ian Campbell wrote:
>>>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
>>>>&g
>>> On 11.01.16 at 15:06, wrote:
> On 13.11.2015 10:50, Ian Campbell wrote:
>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
How do you express modules other than kernel+initrd in that
scheme, without grub needing to be aware of any new addition we
may find necessary go
>>> On 12.11.15 at 18:09, wrote:
> On Thu, 2015-11-12 at 08:44 -0700, Jan Beulich wrote:
>> > > > On 12.11.15 at 14:41, wrote:
>> > Hello, all. I'd like to have set of commands that would boot xen on all
>> > platforms. I thought of followi
>>> On 12.11.15 at 17:58, wrote:
> 12.11.2015 18:44, Jan Beulich пишет:
>>>>> On 12.11.15 at 14:41, wrote:
>>> Hello, all. I'd like to have set of commands that would boot xen on all
>>> platforms. I thought of following set:
>>&
>>> On 12.11.15 at 14:41, wrote:
> Hello, all. I'd like to have set of commands that would boot xen on all
> platforms. I thought of following set:
>
> xen_hypervisor FILE XEN_OPTIONS
> xen_kernel FILE KERNEL_OPTIONS
> xen_initrd INITRD INITRD INITRD
> all initrds are concatenated.
> xen_xsm ???
>>> On 22.09.15 at 19:03, wrote:
> On Thu, Aug 27, 2015 at 06:43:39AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > +#define __packed __attribute__((__packed__))
>> > +#define __text__attribute__
>>> On 22.09.15 at 17:21, wrote:
> On Thu, Aug 27, 2015 at 06:01:26AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > @@ -130,6 +146,119 @@ print_err:
>> > .Lhalt: hlt
>> > jmp .Lhalt
>> >
>
>>> On 31.08.15 at 21:49, wrote:
> On Fri, Aug 28, 2015 at 08:16:05AM -0600, Jan Beulich wrote:
>> >>> On 28.08.15 at 15:42, wrote:
>> > Now that said - do you have suggestions on how to make this work
>> > with GRUB in the picture?
>>
>>
>>> On 27.08.15 at 17:29, wrote:
> You're right, there's no such requirement on memory use in the spec.
> But you're missing the point. Supporting grub2 on UEFI is already a
> hack (ignoring all intentions EFI had from its first days). And now
> you've found an environment where that hack needs an
>>> On 28.08.15 at 15:42, wrote:
> 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.'
Well, not the least since I don't really agree with this (albeit I can
see where you're coming from) ...
> Now that s
>>> 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 ef
>>> On 27.08.15 at 20:04, wrote:
> On 27/08/15 16:29, Jan Beulich wrote:
>>>>> On 27.08.15 at 17:10, wrote:
>>> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>>>>>>> On 20.07.15 at 16:29, wrote:
>>>
>>> On 27.08.15 at 17:10, wrote:
> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > /* Copy bootstrap trampoline to low memory, below 1MB. */
>> > -mov $sym_phys(trampoline
>>> On 20.07.15 at 16:29, wrote:
> - %fs register is filled with segment descriptor which describes memory
> region
> with Xen image (it could be relocated or not);
This is too fuzzy. Please be very precise which region it is that %fs
is supposed to point to (so that reviewers have a chanc
>>> On 20.07.15 at 16:29, 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 w
>>> On 20.07.15 at 16:29, wrote:
> Signed-off-by: Daniel Kiper
For a patch of this size, no description at all seems rather
problematic.
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -89,6 +89,13 @@ multiboot1_header_end:
> 0, /* Number of the lines
>>> On 20.07.15 at 16:29, 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,
>>> On 26.08.15 at 14:33, wrote:
> Do you suggest that I should put this functionality (PE with multiboot
> headers) on top of this patch series? Well, it is possible but this
> series is big and I would like to avoid to make it bigger. I prefer to
> get current patches into Xen tree and then work
>>> On 25.08.15 at 18:31, wrote:
> On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote:
>> >>> On 24.08.15 at 22:54, wrote:
>> > On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote:
>> >> >>> On 22.08.15 at 15:59, wro
>>> On 24.08.15 at 22:54, wrote:
> On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote:
>> >>> On 22.08.15 at 15:59, wrote:
>> > On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
>> >> >>> On 20.07.15 at 16:29, wrote
>>> On 22.08.15 at 14:33, wrote:
> On Thu, Aug 20, 2015 at 09:18:17AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > --- a/xen/arch/x86/efi/stub.c
>> > +++ b/xen/arch/x86/efi/stub.c
>> > @@ -4,9 +4,14 @@
>>
>>> On 22.08.15 at 15:59, wrote:
> On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > Build xen.gz with EFI code. We need this to support multiboot2
>> > protocol on EFI platforms.
>> >
&g
al check here.
Similarly in patch 17.
With these minor adjustments, all the "efi: split out efi_..." patches
Acked-by: Jan Beulich
Jan
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>>> On 20.07.15 at 16:29, 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
DYM "a non-ELF file"?
> it must contain "linear" (or "flat") representation of code and data
>>> On 20.07.15 at 16:29, wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -4,9 +4,14 @@
> #include
> #include
>
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> -#endif
> +struct efi __read_mostly efi = {
> + .flags = 0, /* Initialized later. */
> +
>>> On 18.08.15 at 14:00, wrote:
> On Tue, Aug 18, 2015 at 02:12:58AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > @@ -119,10 +213,11 @@ __start:
>> >
>> > /* Save the Multiboot info struct (after relocation) f
multiboot2.h to Makefile
> (suggested by Jan Beulich),
With the compiler.h inclusion done I don't think this is as necessary
anymore as it was previously.
>- isolated/stray __packed attribute usage for multiboot2_memory_map_t
> (suggested by Jan Beulich).
This one I don'
n.
>
> Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
ions/fixes:
>- generalize new functions names
> (suggested by Jan Beulich),
>- reduce number of casts
> (suggested by Jan Beulich).
This contradicts retaining Andrew's R-b tag. Please remember to
drop tags for everything you make non-trivial changes to.
> @@ -55
>>> On 20.07.15 at 16:28, wrote:
An empty description leaves us guess at the "why".
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -10,15 +10,27 @@
> *Keir Fraser
> */
>
> -/* entered with %eax = BOOT_TRAMPOLINE */
> +/*
> + * This entry point is entered from
>>> On 14.08.15 at 16:37, wrote:
> On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 15:59, wrote:
>> > On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >> >>> On 14.08.15 at 13:52, wrote:
>>> On 14.08.15 at 15:59, wrote:
> On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 13:52, wrote:
>> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> >> On Mon, Jul 20, 2015 at 04:29:17PM
>>> On 14.08.15 at 13:52, wrote:
> On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
>> > diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
>> > index 87b3341..27481ac 100644
>> > --- a/xen/inc
>>> On 13.08.15 at 21:22, wrote:
> On Mon, Aug 10, 2015 at 03:17:48PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 20, 2015 at 04:29:03PM +0200, Daniel Kiper wrote:
>> > @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER
>> > /
>> > .long -(MULTIBOOT_HEA
>>> On 20.07.15 at 16:28, wrote:
> This series, in general, is not targeted to Xen 4.6. However, there are
> some fixes at the beginning of it which are worth considering, I think.
I looked at the first few, and didn't spot any fixes. If you meant
just cleanup or other cosmetic adjustments, then
>>> On 27.03.15 at 15:57, wrote:
> On Fri, Mar 27, 2015 at 02:34:19PM +, Jan Beulich wrote:
>> >>> On 27.03.15 at 15:26, wrote:
>> > On Fri, Mar 27, 2015 at 01:36:32PM +, Jan Beulich wrote:
>> >> >>> On 27.03.15 at 14:06, wro
>>> On 27.03.15 at 15:26, wrote:
> On Fri, Mar 27, 2015 at 01:36:32PM +, Jan Beulich wrote:
>> >>> On 27.03.15 at 14:06, wrote:
>> > On Tue, Mar 17, 2015 at 10:32:01AM +, Jan Beulich wrote:
>> >> >>> On 30.01.15 at 18:54, wrote:
&
>>> On 27.03.15 at 15:09, wrote:
> On Fri, Mar 27, 2015 at 02:04:22PM +, Jan Beulich wrote:
>> >>> On 27.03.15 at 14:53, wrote:
>> > On 27/03/15 13:43, Jan Beulich wrote:
>> >>>>> On 27.03.15 at 14:32, wrote:
>> >>> On
>>> On 27.03.15 at 14:53, wrote:
> On 27/03/15 13:43, Jan Beulich wrote:
>>>>> On 27.03.15 at 14:32, wrote:
>>> On Fri, Feb 20, 2015 at 04:17:35PM +, Jan Beulich wrote:
>>>>>>> On 30.01.15 at 18:54, wrote:
>>>>> We ne
>>> On 27.03.15 at 14:32, wrote:
> On Fri, Feb 20, 2015 at 04:17:35PM +, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, wrote:
>> > We need more fine grained knowledge about EFI environment and check
>> > for EFI platform and EFI loader s
>>> On 27.03.15 at 14:06, wrote:
> On Tue, Mar 17, 2015 at 10:32:01AM +, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, wrote:
>> > +/* Skip Multiboot2 information fixed part */
>> > +lea MB2_fixed_sizeof(%ebx),%ecx
>
>>> On 27.03.15 at 13:57, wrote:
> On Mon, Mar 02, 2015 at 05:23:49PM +, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, wrote:
>> > +{
>> > +void *ptr;
>> > +
>> > +/*
>> > + * Init __malloc_free on r
>>> On 27.03.15 at 13:22, wrote:
> On Fri, Mar 27, 2015 at 11:20:10AM +, Jan Beulich wrote:
>> >>> On 27.03.15 at 11:56, wrote:
>> > On Fri, Feb 20, 2015 at 04:06:26PM +, Jan Beulich wrote:
>> >> >>> On
>>> On 27.03.15 at 13:00, wrote:
> Additionally, efi_start()
> is architecture independent and efi_multiboot2() is x86 only and it should
> live in x86 files.
Is that really the case? Looking at the grub2 sources I see support
for other than x86...
Jan
_
>>> On 27.03.15 at 12:14, wrote:
> IIRC, MS ABI is supported starting from GCC v4.0.
Where did you find that? From all I know __attribute__((__ms_abi__))
is being supported only by 4.5 and newer. The mere support of the
MS ABI via command line option doesn't help us, as we need to be
able to mix
>>> On 27.03.15 at 11:56, wrote:
> On Fri, Feb 20, 2015 at 04:06:26PM +, Jan Beulich wrote:
>> >>> On 30.01.15 at 18:54, wrote:
>> > --- a/xen/arch/x86/boot/Makefile
>> > +++ b/xen/arch/x86/boot/Makefile
>> > @@ -1,6 +1,7 @@
>&
>>> On 30.01.15 at 18:54, wrote:
> @@ -94,6 +111,17 @@ ENTRY(start)
> gdt_boot_descr:
> .word 6*8-1
> .long sym_phys(trampoline_gdt)
> +.long 0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long sym_phys(cs32_switch)
> +.long BOOT_CS
>>> On 03.03.15 at 00:40, wrote:
> Reviewing the #ifndef CONFIG_ARM in EFI code, and the efi_enabled
> usage elsewhere,
> the remaining EFI tasks on ARM look like:
> * Support for SetVirtualAddressMap
> * Runtime service support - looks like just time function used by x86
> in get_cmos_time()
* P
>>> On 02.03.15 at 21:25, wrote:
> On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich wrote:
>>>>> On 30.01.15 at 18:54, wrote:
>>> @@ -192,12 +218,7 @@ static void __init
>>> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>>>
>&g
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -103,9 +103,35 @@ static void __init relocate_trampoline(unsigned long
> phys)
> *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
> }
>
> +#define __MALLOC_SIZE
>>> On 30.01.15 at 18:54, wrote:
> ..which gets memory map and calls ExitBootServices(). We need this
> to support multiboot2 protocol on EFI platforms.
Patches from 9 up to here all make sense on the basis that patch 18
does and assuming that you really need all this code moved out to
separate f
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,14 +1,14 @@
> CFLAGS += -fshort-wchar
>
> -obj-y += stub.o
> +obj-y += boot.o
> +obj-y += compat.o
> +obj-y += runtime.o
So how is this going to work with a compiler not new enough to
s
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
> tboot_shutdown(TB_SHUTDOWN_REBOOT);
> }
>
> -efi_reset_system(reboot_mode != 0);
> +if ( efi_platform
>>> On 30.01.15 at 18:54, wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol.
... because of ... (i.e. I can't see from the description what the
separation is good for). Looking at the
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
> obj-bin-y += head.o
>
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h
> $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h
> $(BAS
>>> On 10.02.15 at 22:27, wrote:
> After some testing we have found at least one machine on which this thing
> does not work. It is Dell PowerEdge R820 with latest firmware. Machine
> crashes/stops because early 32-bit code is not relocatable and must live
> under 0x10 address. (side note: I a
>>> On 09.02.15 at 18:59, wrote:
> On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
>> I am sending, long awaited, first version of multiboot2 protocol
>> support for legacy BIOS and EFI platforms.
>>
>> The final goal is xen.efi binary file which could be loaded by EFI
>> loader, mul
>>> On 05.02.15 at 12:50, wrote:
> Le 2015-02-04 10:51, "Jan Beulich" a écrit :
>>
>> >>> On 04.02.15 at 10:04, wrote:
>> > On 03/02/2015 17:14, Daniel Kiper wrote:
>> >> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wr
>>> On 04.02.15 at 10:04, wrote:
> On 03/02/2015 17:14, Daniel Kiper wrote:
>> On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, wrote:
>>>> - xen.efi build will not so strongly depend
>>>>
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/boot/reloc.c
> +++ b/xen/arch/x86/boot/reloc.c
> @@ -33,9 +33,10 @@ asm (
> typedef unsigned int u32;
> #include "../../../include/xen/multiboot.h"
>
> -static void *reloc_mbi_struct(void *old, unsigned int bytes)
> +static u32 alloc_struct
>>> On 30.01.15 at 18:54, wrote:
> /* Save the Multiboot info struct (after relocation) for later use.
> */
> mov $sym_phys(cpu0_stack)+1024,%esp
> -push%ebx
> -callreloc
> +mov %ecx,%eax
> +push%ebx/* Multiboot
>>> On 30.01.15 at 18:54, wrote:
> - xen.efi build will not so strongly depend
> on a given GCC and binutils version.
While I can see the possibility of making the binutils version
dependency go away (by manually creating the PE header), I can't
see how you'd overcome the gcc one: The MS ca
>>> On 01.07.14 at 20:27, wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 7/1/2014 12:18 PM, Andrey Borzenkov wrote:
>> В Tue, 01 Jul 2014 12:06:08 -0400 Phillip Susi
>> пишет:
>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>> I have been trying to fix grub to load a
>>> On 28.10.13 at 19:01, Vladimir 'f-coder/phcoder'
>>> Serbinenko wrote:
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
>>> Vladimir 'φ-coder/phcoder' Serbinenko 10/23/13 7:02 PM
>>> >>>
>> GrUB - which iiuc stays in memory
>> after transferring control - could export its file system support to its
>> descendants).
>
>Xen shouldn't need to load any file after multiboot2 entry point. The
>needed files would already
>>> Konrad Rzeszutek Wilk 10/23/13 3:15 PM >>>
>On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
>> 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 et
>>> Ian Campbell 10/23/13 10:32 AM >>>
>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
>>> On 22.10.13 at 16:51, Konrad Rzeszutek Wilk wrote:
> And I still haven't found the module that can launch any PE/COFF
> image from GRUB2. Maybe that is a myth.
I can't exclude that this is a custom a patch as the linuxefi support.
Jan
___
Grub-de
>>> On 22.10.13 at 11:45, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:31 +0100, Jan Beulich wrote:
>> >>> On 22.10.13 at 11:26, Ian Campbell wrote:
>> > AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
>> > Protoc
>>> On 22.10.13 at 15:53, 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
>>> On 22.10.13 at 11:26, Ian Campbell wrote:
> AIUI "efilinux" is somewhat badly named and does not use the Linux Boot
> Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> It actually loads and executes the kernel binary as a PE/COFF executable
> (the native UEFI binary exec
>>> On 21.10.13 at 20:39, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper wrote:
>> > Separate multiboot2efi module should be established. It should verify
>> > system
>
>>> On 21.10.13 at 20:46, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 03:37:21PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > However my understanding is that the general distro approach is
>>> On 21.10.13 at 16:23, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 14:57, Daniel Kiper wrote:
>>
>> (Looking at the Cc list it's quite interesting that you copied a
>> wh
>>> On 21.10.13 at 14:57, Daniel Kiper wrote:
(Looking at the Cc list it's quite interesting that you copied a
whole lot of people, but not me as the maintainer of the EFI
bits in Xen.)
> Separate multiboot2efi module should be established. It should verify system
> kernel and all loaded modules
80 matches
Mail list logo
