From: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
To: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
Jerry Hoemann <jerry.hoemann-VXdhtT5mjnY@public.gmane.org>
Cc: rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
bp-l3A5Bk7waGM@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mingo.kernel.org-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: Re: [RFC v2 0/2] Early use of boot service memory
Date: Thu, 21 Nov 2013 15:18:41 -0800 [thread overview]
Message-ID: <528E94D1.2050809@zytor.com> (raw)
In-Reply-To: <20131121230744.GA31592-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
On 11/21/2013 03:07 PM, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 02:01:24PM -0700, Jerry Hoemann wrote:
>>
>> Some platform have firmware that violates the UEFI spec and access boot
>> service code or data segments after the system has called ExitBootServices().
>> The call to efi_reserve_boot_services in setup_arch is a workaround to
>> avoid using boot service memory until after the kernel has done
>> SetVirtualAddressMap. However, this reservation fragments memory
>> which can cause large allocations early in boot (e.g. crash kernel)
>> to fail.
>
> This is a problem we have to solve, but I don't think this is the right
> way to solve it. Why do we not just reattempt to perform the allocation
> immediately after we've freed the boot services regions?
>
Wouldn't the memory map already have gotten scrambled all to hell by then?
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>,
Jerry Hoemann <jerry.hoemann@hp.com>
Cc: rob@landley.net, tglx@linutronix.de, mingo@redhat.com,
x86@kernel.org, matt.fleming@intel.com, yinghai@kernel.org,
akpm@linux-foundation.org, bp@suse.de, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
penberg@kernel.org, mingo.kernel.org@gmail.com,
vgoyal@redhat.com
Subject: Re: [RFC v2 0/2] Early use of boot service memory
Date: Thu, 21 Nov 2013 15:18:41 -0800 [thread overview]
Message-ID: <528E94D1.2050809@zytor.com> (raw)
In-Reply-To: <20131121230744.GA31592@srcf.ucam.org>
On 11/21/2013 03:07 PM, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 02:01:24PM -0700, Jerry Hoemann wrote:
>>
>> Some platform have firmware that violates the UEFI spec and access boot
>> service code or data segments after the system has called ExitBootServices().
>> The call to efi_reserve_boot_services in setup_arch is a workaround to
>> avoid using boot service memory until after the kernel has done
>> SetVirtualAddressMap. However, this reservation fragments memory
>> which can cause large allocations early in boot (e.g. crash kernel)
>> to fail.
>
> This is a problem we have to solve, but I don't think this is the right
> way to solve it. Why do we not just reattempt to perform the allocation
> immediately after we've freed the boot services regions?
>
Wouldn't the memory map already have gotten scrambled all to hell by then?
-hpa
next prev parent reply other threads:[~2013-11-21 23:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 21:01 [RFC v2 0/2] Early use of boot service memory Jerry Hoemann
2013-11-21 21:01 ` [RFC v2 1/2] efi: " Jerry Hoemann
2013-11-21 21:01 ` [RFC v2 2/2] x86, " Jerry Hoemann
2013-11-21 22:19 ` Borislav Petkov
[not found] ` <1385067686-73500-1-git-send-email-jerry.hoemann-VXdhtT5mjnY@public.gmane.org>
2013-11-21 23:07 ` [RFC v2 0/2] " Matthew Garrett
2013-11-21 23:07 ` Matthew Garrett
[not found] ` <20131121230744.GA31592-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-11-21 23:18 ` H. Peter Anvin [this message]
2013-11-21 23:18 ` H. Peter Anvin
2013-11-21 23:37 ` Matthew Garrett
2013-11-22 1:12 ` H. Peter Anvin
2013-11-22 1:25 ` jerry.hoemann
[not found] ` <20131122012524.GA5627-dMAi7lA+vBPDUbYHzcRnttBPR1lH4CV8@public.gmane.org>
2013-11-22 1:29 ` Yinghai Lu
2013-11-22 1:29 ` Yinghai Lu
[not found] ` <CAE9FiQUx5rnA0kpqXRQYtpj9Qk-4bPGaUKEbbF=XHsZbnSd6Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-22 1:31 ` H. Peter Anvin
2013-11-22 1:31 ` H. Peter Anvin
2013-11-22 2:34 ` Vivek Goyal
[not found] ` <20131122023406.GG31921-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-22 2:42 ` H. Peter Anvin
2013-11-22 2:42 ` H. Peter Anvin
2013-11-22 2:32 ` Vivek Goyal
2013-11-22 2:32 ` Vivek Goyal
2013-11-22 2:29 ` Vivek Goyal
[not found] ` <20131122022957.GE31921-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-22 3:32 ` HATAYAMA Daisuke
2013-11-22 3:32 ` HATAYAMA Daisuke
2013-11-21 23:31 ` jerry.hoemann-VXdhtT5mjnY
2013-11-21 23:31 ` jerry.hoemann
2013-11-21 23:38 ` Matthew Garrett
[not found] ` <20131121233831.GB32121-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
2013-11-22 1:05 ` jerry.hoemann-VXdhtT5mjnY
2013-11-22 1:05 ` jerry.hoemann
2013-11-22 1:16 ` Matthew Garrett
2013-12-16 18:43 ` jerry.hoemann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528E94D1.2050809@zytor.com \
--to=hpa-ymnouzjc4hwavxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=bp-l3A5Bk7waGM@public.gmane.org \
--cc=jerry.hoemann-VXdhtT5mjnY@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=mingo.kernel.org-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org \
--cc=penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.