The timer is shutdown before callbacks on exitbootservices are called. The
bios should be entirely single threaded at this point unless Linux has started
some other CPUs. So exitbootservices will not return until each until each
callback is complete. In short, then it would return the status
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 th
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 sign
From: Borislav Petkov
Add the ability to map pages in an arbitrary pgd.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/mm/pageattr.c | 82
2 files changed, 67 insertions(+), 18 deletions(-)
diff --gi
From: Borislav Petkov
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 that when the k
From: Borislav Petkov
... to void * like the boot services and lose all the void * casts. No
functionality change.
Signed-off-by: Borislav Petkov
---
arch/x86/boot/compressed/eboot.c | 2 +-
arch/x86/include/asm/efi.h | 28 ++--
include/linux/efi.h |
From: Borislav Petkov
.. for passing miscellaneous options from the kernel command line.
Signed-off-by: Borislav Petkov
---
arch/x86/platform/efi/efi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 82089
From: Borislav Petkov
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 is, we're ke
On Mon, 17 Jun, at 12:02:05PM, Jan Beulich wrote:
> >>> On 17.06.13 at 12:17, Matt Fleming 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
> cover.
I ge
>>> On 17.06.13 at 12:17, Matt Fleming 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 resulting from gene
於 一，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 i
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 s
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
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/platf
>>> On 17.06.13 at 11:21, Matt Fleming wrote:
> On Fri, 14 Jun, at 12:00:33AM, joeyli wrote:
>> > From: Zach Bobroff
>> > --- 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 boot_params
>> > *boot_pa
On Fri, 14 Jun, at 12:00:33AM, joeyli wrote:
> Hi Zach,
>
> 於 二，2013-06-11 於 07:52 +0100，Matt Fleming 提到：
> > From: Zach Bobroff
> >
> > ExitBootServices is absolutely supposed to return a failure if any
> > ExitBootServices event handler changes the memory map. Basically the
> > get_map loop
15 matches
Mail list logo
