On Mon, Nov 04, 2013 at 08:41:11PM +, Stefano Stabellini wrote:
> >
> > multiboot2 protocol requires some more changes. However, about 80% of code
> > is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> > that all images could be placed on any filesystem recognized by
On Wed, 30 Oct 2013, Daniel Kiper wrote:
> Hi,
>
> Here is a short summary of our discussion. It looks
> that we have two choices right now:
> - chainloader,
> - multiboot2 protocol.
>
> chainloader solution could be implemented quite easily. Some code should be
> added for command line parsi
On 30.10.2013 12:19, Daniel Kiper wrote:
> Hi,
> multiboot2 protocol requires some more changes. However, about 80% of code
> is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> that all images could be placed on any filesystem recognized by GRUB2. Options
> for Xen and mo
Hi,
Here is a short summary of our discussion. It looks
that we have two choices right now:
- chainloader,
- multiboot2 protocol.
chainloader solution could be implemented quite easily. Some code should be
added for command line parsing. However, all arguments for Xen itself and
modules must
>>> 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
Hi,
Quoting Konrad Rzeszutek Wilk, who wrote the following on Mon, 28 Oct 2013:
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
>>> 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 - t
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,
> >>
> >
>>> 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
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> > - Do the signature verification (hand-waving which one - probably both).
> Can someone throw me the link on the EFI signature specification? Can't
> really find it now.
It is in UEFI specs, specifically chapter 2
> 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 be in memory with pointers to them passed.
If you insist on being able to
>>> 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 23.10.2013 15:13, Konrad Rzeszutek Wilk wrote:
> - not make an ExitBootServices call - which it does right now in the Solaris
>GRUB2 case and in the Fedora GRUB2 case.
What about having a special tag in multiboot2 file header "RKEBSIHE":
"request to keep EFI boot services" and then bootload
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/
On 23.10.2013 09:05, Daniel Kiper wrote:
> Thanks. Could you send me a pointer to current multiboot2 protocol docs?
It's managed as "multiboot2" branch in our repo:
http://git.savannah.gnu.org/cgit/grub.git
Note: we're in process of moving from bzr to git which may cause the
link to change.
sign
On 23.10.2013 09:43, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 11:16:24PM +0200, 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
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 she
> On Oct 23, 2013, at 12:05 AM, Daniel Kiper wrote:
>
>> 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 whol
On Tue, Oct 22, 2013 at 05:21:15PM +, Maliszewski, Richard L wrote:
> The latter. The code I was looking at definitely has the linuxefi
> directive. FWIW, if you install FC18/19 on an EFI system, the grub2
> config file uses the linuxefi and companion initrd directives for launch.
>
> --Richa
On Mon, Oct 21, 2013 at 11:16:24PM +0200, 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
> >
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,
> >>
> >
On Tue, Oct 22, 2013 at 09:42:52AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> > >>> 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:
2013/10/23 Michael Chang :
> 2013/10/23 Konrad Rzeszutek Wilk :
>> On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>>> >
>>> > And looking at bit deeper in the x86/linux boot spec:
>>> >
>>> > EFI HANDOVER PR
2013/10/23 Konrad Rzeszutek Wilk :
> On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>> >
>> > And looking at bit deeper in the x86/linux boot spec:
>> >
>> > EFI HANDOVER PROTOCOL
>> >
>> > This protocol allo
On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>
> And looking at bit deeper in the x86/linux boot spec:
>
> EFI HANDOVER PROTOCOL
>
>
>
>
The latter. The code I was looking at definitely has the linuxefi
directive. FWIW, if you install FC18/19 on an EFI system, the grub2
config file uses the linuxefi and companion initrd directives for launch.
--Richard
On 10/22/13 9:51 AM, "Daniel Kiper" wrote:
>On Tue, Oct 22, 2013 at 04:36:0
On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>
> There are two problems with this:
>
> 1) The kernel will only boot if it's signed with a key in db, not a key
> in MOK.
> 2) grub will read the kernel, but the kernel will have to read the
> initramfs using EFI calls. That means your
s.philip...@citrix.com,stefano.stabell...@eu.citrix.com,grub-devel@gnu.org,"Woodhouse,
David" ,"Maliszewski, Richard L"
,xen-de...@lists.xen.org,boris.ostrov...@oracle.com,Daniel
Kiper ,Peter Jones
,linux-ker...@vger.kernel.org,k...@xen.org
Subject: Re: EFI and multiboot2 devlopment work for
On 22.10.2013 19:12, Andrey Borzenkov wrote:
> В Mon, 21 Oct 2013 23:16:24 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko пишет:
>
>> GRUB has generic support for signing kernels/modules/whatsoever using
>> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
>> method doesn't ha
В Mon, 21 Oct 2013 23:16:24 +0200
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> GRUB has generic support for signing kernels/modules/whatsoever using
> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
> method doesn't have any controversy associated with EFI stuff but at
>
On 22.10.2013 18:51, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 04:36:04PM +, Maliszewski, Richard L wrote:
>> I may be off-base, but when I was wading through the grub2 code earlier
>> this year, it looked to me like it was going to refuse to launch anything
>> via MB1 or MB2 if the current
On Tue, Oct 22, 2013 at 04:36:04PM +, Maliszewski, Richard L wrote:
> I may be off-base, but when I was wading through the grub2 code earlier
> this year, it looked to me like it was going to refuse to launch anything
> via MB1 or MB2 if the current state was a secure boot launch.
Are you talk
> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> > of this stuff to me, it might be useful for you to get it from the
> > horses mouth instead of laundered through my brain (which is a bit
> > addled afterwards ;-)).
>
> Sadly no. However, if it is possible/needed I co
On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > And looking at bit deeper in the x86/linux boot spec:
> >
> > EFI HANDOVER PROTOCOL
> >
> >
On Tue, Oct 22, 2013 at 05:39:24PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote:
> > If you use 'linux' module, it will call ExitBootService.
> > If you use 'multiboot' module, it will call ExitBootService too.
> >
> > So if you don't want
On Tue, 2013-10-22 at 18:25 +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> On 22.10.2013 18:14, Daniel Kiper wrote:
> >> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
> >> > of this stuff to me, it might be useful for you to get it from the
> >> > horses mouth ins
On Tue, 2013-10-22 at 12:24 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 04:21:47PM +0100, Ian Campbell wrote:
> > On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> > > That 'that' is a standard PE/COFF image? Could you please point me
> > > to the code that does t
On 22.10.2013 18:14, Daniel Kiper wrote:
>> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
>> > of this stuff to me, it might be useful for you to get it from the
>> > horses mouth instead of laundered through my brain (which is a bit
>> > addled afterwards ;-)).
What and
On Tue, Oct 22, 2013 at 04:22:38PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 15:24 +0100, Ian Campbell wrote:
> > On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
> >
> > > So it can be booted the same way as xen.efi. But my understanding is
> > > that folks prefer a bootlo
On 22.10.2013 18:01, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>
>>> There are two problems with this:
>>>
>>> 1) The kernel will only boot if it's signed with a key in db, not a key
>>> in
On Tue, Oct 22, 2013 at 04:21:47PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> > That 'that' is a standard PE/COFF image? Could you please point me
> > to the code that does that in GRUB2?
>
> As I said earlier in the thread, it's a patch which i
On Tue, Oct 22, 2013 at 05:08:03PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 18:01 +0200, Daniel Kiper wrote:
> > On Tue, Oct 22, 2013 at 03:42:42PM +, Woodhouse, David wrote:
> > > On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> > > >
> > > > There are two problems with th
On Tue, 2013-10-22 at 18:01 +0200, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +, Woodhouse, David wrote:
> > On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> > >
> > > There are two problems with this:
> > >
> > > 1) The kernel will only boot if it's signed with a key i
On Tue, Oct 22, 2013 at 03:42:42PM +, Woodhouse, David wrote:
> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
> >
> > There are two problems with this:
> >
> > 1) The kernel will only boot if it's signed with a key in db, not a key
> > in MOK.
> > 2) grub will read the kernel, but t
On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote:
> If you use 'linux' module, it will call ExitBootService.
> If you use 'multiboot' module, it will call ExitBootService too.
>
> So if you don't want to the module to call 'grub_efi_finish_boot_services'
> you need to use 'linuxefi' :-)
That's a v
On Tue, Oct 22, 2013 at 10:51:40AM -0400, 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.
"chainload" will do this. In fact, it doesn't do much:
static grub_err_t
grub_chainloader_boot (void)
{
grub_efi_b
On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
> Oh, ignore that. You want the *actual* PE executable entry point, as it
> would get invoked by a real UEFI firmware.
There are two problems with this:
1) The kernel will only boot if it's signed with a key in db, not a key
in M
On Tue, 2013-10-22 at 14:18 +, Woodhouse, David wrote:
> > I wonder why Linux can't make the EFI calls to fetch them itself?
>
> It can. It does. It prefers to. This is what the "EFI boot stub" is all about.
Good, this is what I thought, glad to see I'm not talking out my behind
for once!
>
On Tue, 2013-10-22 at 15:24 +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
>
> > 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 p
On Tue, 2013-10-22 at 10:57 -0400, Konrad Rzeszutek Wilk wrote:
> That 'that' is a standard PE/COFF image? Could you please point me
> to the code that does that in GRUB2?
As I said earlier in the thread, it's a patch which is being carried by
all the distros. It is not in upstream grub.
For ins
>>> 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 Tue, Oct 22, 2013 at 02:18:52PM +, Woodhouse, David wrote:
>
> > I wonder why Linux can't make the EFI calls to fetch them itself?
>
> It can. It does. It prefers to. This is what the "EFI boot stub" is all
> about. But grub2 is crack-inspired and likes to do all kinds of crap that it
>
On Tue, Oct 22, 2013 at 03:24:28PM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
>
> > 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
On Tue, Oct 22, 2013 at 09:42:52AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> > >>> 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:
On Tue, 2013-10-22 at 10:09 -0400, Konrad Rzeszutek Wilk wrote:
> 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 majo
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!
>
> (Intere
>>> 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
>> > Protocol (i.e. the (b)zImage stuff with real mode entry point) e
On Tue, Oct 22, 2013 at 10:59:33AM +0100, Jan Beulich wrote:
> >>> 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
>>> 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 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
>>> 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 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
> > Protocol (i.e. the (b)zImage stuff with real mode entry point) either.
> > It actually loads and executes the kernel
On Mon, 2013-10-21 at 20:57 +0200, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 09:54:38AM -0400, Peter Jones wrote:
> > On Mon, Oct 21, 2013 at 02:57:56PM +0200, Daniel Kiper wrote:
> > > Hi,
> > >
> > > During work on multiboot2 protocol support for Xen it was discovered
> > > that memory map pa
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
>>> 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
>> > kernel and all loaded modules using shim on EF
>>> 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
>> > to use GRUB2 and I think we want to follow the m
Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:
On 21.10.2013 22:53, Seth Goldberg wrote:
Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
Hi,
During work on multiboot2 protocol support for Xen it was discovered
that memory map passed via r
On 21.10.2013 22:53, Seth Goldberg wrote:
>
>
> Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
>
>> 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 avai
Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
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 cal
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 Mon, Oct 21, 2013 at 03:37:21PM +0100, Jan Beulich wrote:
> >>> 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:
[...]
> >> > What do you think about that?
> >> > Any
>>> 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
>> whole lot of people, but not me as the maintainer of th
On Mon, Oct 21, 2013 at 09:54:38AM -0400, Peter Jones wrote:
> On Mon, Oct 21, 2013 at 02:57:56PM +0200, 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
On Mon, Oct 21, 2013 at 02:57:56PM +0200, 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 c
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
> whole lot of people, but not me as the maintainer of the EFI
> bits in Xen.)
I see this:
From: Daniel Kiper
To: bo
>>> 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
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
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
> > kernel and all loaded modules using shim on EFI platforms with enabled
> > secure boot
>
> Each
79 matches
Mail list logo
