On Fri, 14 Jun, at 12:00:33AM, joeyli wrote:
Hi Zach,
於 二，2013-06-11 於 07:52 +0100，Matt Fleming 提到：
From: Zach Bobroff zacha...@ami.com
ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map. Basically the
get_map
On 17.06.13 at 11:21, Matt Fleming m...@console-pimps.org wrote:
On Fri, 14 Jun, at 12:00:33AM, joeyli wrote:
From: Zach Bobroff zacha...@ami.com
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -1037,18 +1037,20 @@ static efi_status_t exit_boot(struct
On Sun, 16 Jun, at 09:27:12PM, Ben Hutchings wrote:
1. Check for allocation failure
2. Clear the buffer contents, as they may actually be written to flash
3. Don't leak the buffer
Compile-tested only.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Cc: sta...@vger.kernel.org
---
On Mon, 17 Jun, at 10:46:28AM, Jan Beulich wrote:
To me, all this looks like it is being done on phenomenological basis,
taking a particular build of a particular firmware implementation as
the reference. Imo we shouldn't change the code in this way. This
also applies to the fact that the step
於 一，2013-06-17 於 11:17 +0100，Matt Fleming 提到：
On Mon, 17 Jun, at 10:46:28AM, Jan Beulich wrote:
To me, all this looks like it is being done on phenomenological basis,
taking a particular build of a particular firmware implementation as
the reference. Imo we shouldn't change the code in this
On 17.06.13 at 12:17, Matt Fleming m...@console-pimps.org wrote:
On Mon, 17 Jun, at 10:46:28AM, Jan Beulich wrote:
I agree that there ought to be an upper limit. But a single retry here
again looks like a tailored solution to a particular observed (mis-)
behavior, rather than something
On Mon, 17 Jun, at 12:02:05PM, Jan Beulich wrote:
On 17.06.13 at 12:17, Matt Fleming m...@console-pimps.org wrote:
What value would you suggest for the retry?
I'd be considering something like 5...10, but this to some degree
depends on what odd kinds of behavior this in fact needs to
From: Borislav Petkov b...@suse.de
Hi all,
this is just a snapshot of the current state of affairs. The patchset
starts to boot successfully on real hardware now but we're far away from
the coverage we'd like to have before we even consider upstreaming it.
And yes, considering the sick f*ck EFI
From: Borislav Petkov b...@suse.de
.. for passing miscellaneous options from the kernel command line.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c
From: Borislav Petkov b...@suse.de
... to void * like the boot services and lose all the void * casts. No
functionality change.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/boot/compressed/eboot.c | 2 +-
arch/x86/include/asm/efi.h | 28 ++--
From: Borislav Petkov b...@suse.de
Add the ability to map pages in an arbitrary pgd.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/mm/pageattr.c | 82
2 files changed, 67 insertions(+),
From: Borislav Petkov b...@suse.de
Due to the braindead design of EFI, we cannot map runtime services more
than once for the duration of a booted system. Thus, if we want to use
EFI runtime services in a kexec'ed kernel, maybe the only possible and
sensible approach would be to map them 1:1 so
All,
Why a single retry is having reasonable guarantees to work when the original
one failed (nothing prevents an event handler to do another allocation the
next time through).
This patch is being submitted because of the potential issues that occur when
3rd party option ROMs are signaled
Hi Zach,
於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
All,
Why a single retry is having reasonable guarantees to work when the
original one failed (nothing prevents an event handler to do another
allocation the next time through).
This patch is being submitted because of the
14 matches
Mail list logo
