Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration
On Fri, 11 Oct 2019 at 04:39, Dan Williams wrote: > > On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel > wrote: > > > > On Thu, 10 Oct 2019 at 20:31, Dan Williams wrote: > > > > > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel > > > wrote: > > > > > > > > On Thu, 10 Oct 2019 at 01:19, Dan Williams > > > > wrote: > > > > > > > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > > > > interpretation of the EFI Memory Types as "reserved for a specific > > > > > purpose". > > > > > > > > > > The proposed Linux behavior for specific purpose memory is that it is > > > > > reserved for direct-access (device-dax) by default and not available > > > > > for > > > > > any kernel usage, not even as an OOM fallback. Later, through udev > > > > > scripts or another init mechanism, these device-dax claimed ranges can > > > > > be reconfigured and hot-added to the available System-RAM with a > > > > > unique > > > > > node identifier. This device-dax management scheme implements "soft" > > > > > in > > > > > the "soft reserved" designation by allowing some or all of the > > > > > reservation to be recovered as typical memory. This policy can be > > > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime > > > > > with > > > > > efi=nosoftreserve. > > > > > > > > > > This patch introduces 2 new concepts at once given the entanglement > > > > > between early boot enumeration relative to memory that can optionally > > > > > be > > > > > reserved from the kernel page allocator by default. The new concepts > > > > > are: > > > > > > > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP > > > > > attribute on EFI_CONVENTIONAL memory, update the E820 map with this > > > > > new type. Only perform this classification if the > > > > > CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as > > > > > typical ram. > > > > > > > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for > > > > > a device driver to search iomem resources for application specific > > > > > memory. Teach the iomem code to identify such ranges as "Soft > > > > > Reserved". > > > > > > > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the > > > > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For > > > > > now, just identify and reserve memory of this type. > > > > > > > > > > Cc: > > > > > Cc: Borislav Petkov > > > > > Cc: Ingo Molnar > > > > > Cc: "H. Peter Anvin" > > > > > Cc: Darren Hart > > > > > Cc: Andy Shevchenko > > > > > Cc: Andy Lutomirski > > > > > Cc: Peter Zijlstra > > > > > Cc: Thomas Gleixner > > > > > Cc: Ard Biesheuvel > > > > > Reported-by: kbuild test robot > > > > > Reviewed-by: Dave Hansen > > > > > Signed-off-by: Dan Williams > > > > > > > > For the EFI changes > > > > > > > > Acked-by: Ard Biesheuvel > > > > > > > > although I must admit I don't follow the enum add_efi_mode logic 100% > > > > > > I'm open to suggestions as I'm not sure it's the best possible > > > organization. The do_add_efi_memmap() routine has the logic to > > > translate EFI to E820, but unless "add_efi_memmap" is specified on the > > > kernel command line the EFI memory map is ignored. For > > > soft-reservation support I want to reuse do_add_efi_memmap(), but > > > otherwise avoid any other side effects of considering the EFI map. > > > What I'm missing is the rationale for why "add_efi_memmap" is required > > > before considering the EFI memory map. > > > > > > If there is a negative side effect to always using the EFI map then > > > the new "add_efi_mode" designation constrains it to just the > > > soft-reservation case. > > > > > > > Could we make the presence of any EFI_MEMORY_SP regions imply > > add_efi_memmap? That way, it is guaranteed that we don't regress > > existing systems, while establishing clear and unambiguous semantics > > for new systems that rely on these changes in order to be able to use > > the special purpose memory as intended. > > In fact that's how it works. EFI_MEMORY_SP is unconditionally added. > Other EFI memory types are optionally added with the add_efi_memmap > option. That is not what I meant. Why not behave as if 'add_efi_memmap' was passed if any EFI_MEMORY_SP regions exist?
Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration
On Thu, Oct 10, 2019 at 11:41 AM Ard Biesheuvel wrote: > > On Thu, 10 Oct 2019 at 20:31, Dan Williams wrote: > > > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel > > wrote: > > > > > > On Thu, 10 Oct 2019 at 01:19, Dan Williams > > > wrote: > > > > > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > > > interpretation of the EFI Memory Types as "reserved for a specific > > > > purpose". > > > > > > > > The proposed Linux behavior for specific purpose memory is that it is > > > > reserved for direct-access (device-dax) by default and not available for > > > > any kernel usage, not even as an OOM fallback. Later, through udev > > > > scripts or another init mechanism, these device-dax claimed ranges can > > > > be reconfigured and hot-added to the available System-RAM with a unique > > > > node identifier. This device-dax management scheme implements "soft" in > > > > the "soft reserved" designation by allowing some or all of the > > > > reservation to be recovered as typical memory. This policy can be > > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with > > > > efi=nosoftreserve. > > > > > > > > This patch introduces 2 new concepts at once given the entanglement > > > > between early boot enumeration relative to memory that can optionally be > > > > reserved from the kernel page allocator by default. The new concepts > > > > are: > > > > > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP > > > > attribute on EFI_CONVENTIONAL memory, update the E820 map with this > > > > new type. Only perform this classification if the > > > > CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as > > > > typical ram. > > > > > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for > > > > a device driver to search iomem resources for application specific > > > > memory. Teach the iomem code to identify such ranges as "Soft > > > > Reserved". > > > > > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the > > > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For > > > > now, just identify and reserve memory of this type. > > > > > > > > Cc: > > > > Cc: Borislav Petkov > > > > Cc: Ingo Molnar > > > > Cc: "H. Peter Anvin" > > > > Cc: Darren Hart > > > > Cc: Andy Shevchenko > > > > Cc: Andy Lutomirski > > > > Cc: Peter Zijlstra > > > > Cc: Thomas Gleixner > > > > Cc: Ard Biesheuvel > > > > Reported-by: kbuild test robot > > > > Reviewed-by: Dave Hansen > > > > Signed-off-by: Dan Williams > > > > > > For the EFI changes > > > > > > Acked-by: Ard Biesheuvel > > > > > > although I must admit I don't follow the enum add_efi_mode logic 100% > > > > I'm open to suggestions as I'm not sure it's the best possible > > organization. The do_add_efi_memmap() routine has the logic to > > translate EFI to E820, but unless "add_efi_memmap" is specified on the > > kernel command line the EFI memory map is ignored. For > > soft-reservation support I want to reuse do_add_efi_memmap(), but > > otherwise avoid any other side effects of considering the EFI map. > > What I'm missing is the rationale for why "add_efi_memmap" is required > > before considering the EFI memory map. > > > > If there is a negative side effect to always using the EFI map then > > the new "add_efi_mode" designation constrains it to just the > > soft-reservation case. > > > > Could we make the presence of any EFI_MEMORY_SP regions imply > add_efi_memmap? That way, it is guaranteed that we don't regress > existing systems, while establishing clear and unambiguous semantics > for new systems that rely on these changes in order to be able to use > the special purpose memory as intended. In fact that's how it works. EFI_MEMORY_SP is unconditionally added. Other EFI memory types are optionally added with the add_efi_memmap option.
Re: [PATCH] Ask user input only when CONFIG_X86 or CONFIG_COMPILE_TEST is set to y
Hi Narendra,
On Thu, Oct 10, 2019 at 7:47 PM wrote:
> On Wed, Oct 09, 2019 at 04:11:04PM +0200, Ard Biesheuvel wrote:
> > On Wed, 2 Oct 2019 at 21:44, wrote:
> > >
> > > From: Narendra K
> > >
> > > For the EFI_RCI2_TABLE kconfig option, 'make oldconfig' asks the user
> > > for input as it is a new kconfig option in kernel version 5.4. This patch
> > > modifies the kconfig option to ask the user for input only when CONFIG_X86
> > > or CONFIG_COMPILE_TEST is set to y.
> > >
> > > The patch also makes EFI_RCI2_TABLE kconfig option depend on CONFIG_EFI.
> > >
> > > Signed-off-by: Narendra K
> > > drivers/firmware/efi/Kconfig | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > > index 178ee8106828..6e4c46e8a954 100644
> > > --- a/drivers/firmware/efi/Kconfig
> > > +++ b/drivers/firmware/efi/Kconfig
> > > @@ -181,7 +181,10 @@ config RESET_ATTACK_MITIGATION
> > > reboots.
> > >
> > > config EFI_RCI2_TABLE
> > > - bool "EFI Runtime Configuration Interface Table Version 2 Support"
> > > + bool
> > > + prompt "EFI RCI Table Version 2 Support" if X86 || COMPILE_TEST
Why the split of bool and prompt?
Why not simply add a single line "depends on X86 || COMPILE_TEST"?
> >
> > You can drop the || COMPILE_TEST as well.
>
> I will drop this part of the change in the next version of the patch.
Why drop that part? Isn't it good to have more compile test coverage?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration
On Thu, 10 Oct 2019 at 20:31, Dan Williams wrote: > > On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel > wrote: > > > > On Thu, 10 Oct 2019 at 01:19, Dan Williams wrote: > > > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > > interpretation of the EFI Memory Types as "reserved for a specific > > > purpose". > > > > > > The proposed Linux behavior for specific purpose memory is that it is > > > reserved for direct-access (device-dax) by default and not available for > > > any kernel usage, not even as an OOM fallback. Later, through udev > > > scripts or another init mechanism, these device-dax claimed ranges can > > > be reconfigured and hot-added to the available System-RAM with a unique > > > node identifier. This device-dax management scheme implements "soft" in > > > the "soft reserved" designation by allowing some or all of the > > > reservation to be recovered as typical memory. This policy can be > > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with > > > efi=nosoftreserve. > > > > > > This patch introduces 2 new concepts at once given the entanglement > > > between early boot enumeration relative to memory that can optionally be > > > reserved from the kernel page allocator by default. The new concepts > > > are: > > > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP > > > attribute on EFI_CONVENTIONAL memory, update the E820 map with this > > > new type. Only perform this classification if the > > > CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as > > > typical ram. > > > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for > > > a device driver to search iomem resources for application specific > > > memory. Teach the iomem code to identify such ranges as "Soft Reserved". > > > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the > > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For > > > now, just identify and reserve memory of this type. > > > > > > Cc: > > > Cc: Borislav Petkov > > > Cc: Ingo Molnar > > > Cc: "H. Peter Anvin" > > > Cc: Darren Hart > > > Cc: Andy Shevchenko > > > Cc: Andy Lutomirski > > > Cc: Peter Zijlstra > > > Cc: Thomas Gleixner > > > Cc: Ard Biesheuvel > > > Reported-by: kbuild test robot > > > Reviewed-by: Dave Hansen > > > Signed-off-by: Dan Williams > > > > For the EFI changes > > > > Acked-by: Ard Biesheuvel > > > > although I must admit I don't follow the enum add_efi_mode logic 100% > > I'm open to suggestions as I'm not sure it's the best possible > organization. The do_add_efi_memmap() routine has the logic to > translate EFI to E820, but unless "add_efi_memmap" is specified on the > kernel command line the EFI memory map is ignored. For > soft-reservation support I want to reuse do_add_efi_memmap(), but > otherwise avoid any other side effects of considering the EFI map. > What I'm missing is the rationale for why "add_efi_memmap" is required > before considering the EFI memory map. > > If there is a negative side effect to always using the EFI map then > the new "add_efi_mode" designation constrains it to just the > soft-reservation case. > Could we make the presence of any EFI_MEMORY_SP regions imply add_efi_memmap? That way, it is guaranteed that we don't regress existing systems, while establishing clear and unambiguous semantics for new systems that rely on these changes in order to be able to use the special purpose memory as intended.
Re: [PATCH v6 05/12] x86/efi: EFI soft reservation to E820 enumeration
On Wed, Oct 9, 2019 at 11:45 PM Ard Biesheuvel wrote: > > On Thu, 10 Oct 2019 at 01:19, Dan Williams wrote: > > > > UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the > > interpretation of the EFI Memory Types as "reserved for a specific > > purpose". > > > > The proposed Linux behavior for specific purpose memory is that it is > > reserved for direct-access (device-dax) by default and not available for > > any kernel usage, not even as an OOM fallback. Later, through udev > > scripts or another init mechanism, these device-dax claimed ranges can > > be reconfigured and hot-added to the available System-RAM with a unique > > node identifier. This device-dax management scheme implements "soft" in > > the "soft reserved" designation by allowing some or all of the > > reservation to be recovered as typical memory. This policy can be > > disabled at compile-time with CONFIG_EFI_SOFT_RESERVE=n, or runtime with > > efi=nosoftreserve. > > > > This patch introduces 2 new concepts at once given the entanglement > > between early boot enumeration relative to memory that can optionally be > > reserved from the kernel page allocator by default. The new concepts > > are: > > > > - E820_TYPE_SOFT_RESERVED: Upon detecting the EFI_MEMORY_SP > > attribute on EFI_CONVENTIONAL memory, update the E820 map with this > > new type. Only perform this classification if the > > CONFIG_EFI_SOFT_RESERVE=y policy is enabled, otherwise treat it as > > typical ram. > > > > - IORES_DESC_SOFT_RESERVED: Add a new I/O resource descriptor for > > a device driver to search iomem resources for application specific > > memory. Teach the iomem code to identify such ranges as "Soft Reserved". > > > > A follow-on change integrates parsing of the ACPI HMAT to identify the > > node and sub-range boundaries of EFI_MEMORY_SP designated memory. For > > now, just identify and reserve memory of this type. > > > > Cc: > > Cc: Borislav Petkov > > Cc: Ingo Molnar > > Cc: "H. Peter Anvin" > > Cc: Darren Hart > > Cc: Andy Shevchenko > > Cc: Andy Lutomirski > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Ard Biesheuvel > > Reported-by: kbuild test robot > > Reviewed-by: Dave Hansen > > Signed-off-by: Dan Williams > > For the EFI changes > > Acked-by: Ard Biesheuvel > > although I must admit I don't follow the enum add_efi_mode logic 100% I'm open to suggestions as I'm not sure it's the best possible organization. The do_add_efi_memmap() routine has the logic to translate EFI to E820, but unless "add_efi_memmap" is specified on the kernel command line the EFI memory map is ignored. For soft-reservation support I want to reuse do_add_efi_memmap(), but otherwise avoid any other side effects of considering the EFI map. What I'm missing is the rationale for why "add_efi_memmap" is required before considering the EFI memory map. If there is a negative side effect to always using the EFI map then the new "add_efi_mode" designation constrains it to just the soft-reservation case. It seems for historical reasons the full EFI memmap requires explicit opt-in: 21eb140e x86 boot: only pick up additional EFI memmap if add_efi_memmap flag
Re: [PATCH] Ask user input only when CONFIG_X86 or CONFIG_COMPILE_TEST is set to y
Hi Ard, Thank you for the review comments. On Wed, Oct 09, 2019 at 04:11:04PM +0200, Ard Biesheuvel wrote: > On Wed, 2 Oct 2019 at 21:44, wrote: > > > > From: Narendra K > > > > For the EFI_RCI2_TABLE kconfig option, 'make oldconfig' asks the user > > for input as it is a new kconfig option in kernel version 5.4. This patch > > modifies the kconfig option to ask the user for input only when CONFIG_X86 > > or CONFIG_COMPILE_TEST is set to y. > > > > The patch also makes EFI_RCI2_TABLE kconfig option depend on CONFIG_EFI. > > > > Signed-off-by: Narendra K > > --- > > The patch is created on kernel version 5.4-rc1. > > > > Hi Ard, I have made following changes - > > > > - changed the prompt string from "EFI Runtime Configuration > > Interface Table Version 2 Support" to "EFI RCI Table Version 2 Support" > > as the string crossed 80 char limit. > > > > - added "depends on EFI" so that code builds only when CONFIG_EFI is > > set to y. > > > > - added 'default n' for ease of understanding though default is set to n. > > > > None of these changes are necessary, tbh. 'depends on EFI' is implied > by the placement of the option, and default n is indeed the default. I will drop the changes in the next version of the patch. > > > > drivers/firmware/efi/Kconfig | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > > index 178ee8106828..6e4c46e8a954 100644 > > --- a/drivers/firmware/efi/Kconfig > > +++ b/drivers/firmware/efi/Kconfig > > @@ -181,7 +181,10 @@ config RESET_ATTACK_MITIGATION > > reboots. > > > > config EFI_RCI2_TABLE > > - bool "EFI Runtime Configuration Interface Table Version 2 Support" > > + bool > > + prompt "EFI RCI Table Version 2 Support" if X86 || COMPILE_TEST > > You can drop the || COMPILE_TEST as well. I will drop this part of the change in the next version of the patch. -- With regards, Narendra K
Re: [PATCH v3 1/3] x86/boot: Introduce the kernel_info
On 10/10/19 2:43 AM, Daniel Kiper wrote: > On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote: >> Hi, >> >> Questions and comments below... >> Thanks. >> >> On 10/9/19 3:53 AM, Daniel Kiper wrote: >> >>> Suggested-by: H. Peter Anvin >>> Signed-off-by: Daniel Kiper >>> Reviewed-by: Konrad Rzeszutek Wilk >>> Reviewed-by: Ross Philipson >>> --- >> >>> --- >>> Documentation/x86/boot.rst | 121 >>> + >>> arch/x86/boot/Makefile | 2 +- >>> arch/x86/boot/compressed/Makefile | 4 +- >>> arch/x86/boot/compressed/kernel_info.S | 17 + >>> arch/x86/boot/header.S | 1 + >>> arch/x86/boot/tools/build.c| 5 ++ >>> arch/x86/include/uapi/asm/bootparam.h | 1 + >>> 7 files changed, 148 insertions(+), 3 deletions(-) >>> create mode 100644 arch/x86/boot/compressed/kernel_info.S >>> >>> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst >>> index 08a2f100c0e6..d5323a39f5e3 100644 >>> --- a/Documentation/x86/boot.rst >>> +++ b/Documentation/x86/boot.rst >>> @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field >>> and extension fields >>> Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in >>> xloadflags to support booting a 64-bit kernel from 32-bit >>> EFI >>> + >>> +Protocol 2.14: BURNT BY INCORRECT COMMIT >>> ae7e1238e68f2a472a125673ab506d49158c1889 >>> + (x86/boot: Add ACPI RSDP address to setup_header) >>> + DO NOT USE!!! ASSUME SAME AS 2.13. >>> + >>> +Protocol 2.15: (Kernel 5.5) Added the kernel_info. >>> = >>> >>> >>> +.. note:: >>> + The protocol version number should be changed only if the setup header >>> + is changed. There is no need to update the version number if >>> boot_params >>> + or kernel_info are changed. Additionally, it is recommended to use >>> + xloadflags (in this case the protocol version number should not be >>> + updated either) or kernel_info to communicate supported Linux kernel >>> + features to the boot loader. Due to very limited space available in >>> + the original setup header every update to it should be considered >>> + with great care. Starting from the protocol 2.15 the primary way to >>> + communicate things to the boot loader is the kernel_info. >>> + >>> >>> Memory Layout >>> = >>> @@ -207,6 +224,7 @@ Offset/Size Proto Name >>> Meaning >>> 0258/8 2.10+ pref_addressPreferred >>> loading address >>> 0260/4 2.10+ init_size Linear memory >>> required during initialization >>> 0264/4 2.11+ handover_offset Offset of >>> handover entry point >>> +0268/4 2.15+ kernel_info_offset Offset of the >>> kernel_info >>> ==== >>> >>> >>> .. note:: >>> @@ -855,6 +873,109 @@ Offset/size: 0x264/4 >>> >>>See EFI HANDOVER PROTOCOL below for more details. >>> >>> + == >>> +Field name:kernel_info_offset >>> +Type: read >>> +Offset/size: 0x268/4 >>> +Protocol: 2.15+ >>> + == >>> + >>> + This field is the offset from the beginning of the kernel image to the >>> + kernel_info. It is embedded in the Linux image in the uncompressed >> ^^ >>What does It refer to, please? > > s/It/The kernel_info structure/ Is it better? Yes. >>> + protected mode region. >>> + >>> + >>> +The kernel_info >>> +=== >>> + >>> +The relationships between the headers are analogous to the various data >>> +sections: >>> + >>> + setup_header = .data >>> + boot_params/setup_data = .bss >>> + >>> +What is missing from the above list? That's right: >>> + >>> + kernel_info = .rodata >>> + >>> +We have been (ab)using .data for things that could go into .rodata or .bss >>> for >>> +a long time, for lack of alternatives and -- especially early on -- >>> inertia. >>> +Also, the BIOS stub is responsible for creating boot_params, so it isn't >>> +available to a BIOS-based loader (setup_data is, though). >>> + >>> +setup_header is permanently limited to 144 bytes due to the reach of the >>> +2-byte jump field, which doubles as a length field for the structure, >>> combined >>> +with the size of the "hole" in struct boot_params that a protected-mode >>> loader >>> +or the BIOS stub has to copy it into. It is currently 119 bytes long, which >>> +leaves us with 25 very precious bytes. This isn't something that can be >>> fixed >>> +without revising the boot protocol entirely, breaking backwards >>> compatibility. >>> + >>> +boot_params proper is limited to 4096 byt
Apply For Financial investment at a lower rate 2%
-- Hello, We are private lenders based in UK. Do you need a loan (credit) as soon as possible. Are you in search of money to solve your personal needs or finance your business venture, then get Your desired loan today! Consult us at Sunrise Funding Ltd. * We offer personal loan & huge capital loan at 2% interest rate to the general public both locally and internationally. * Credit amount range from $5,000.00 -- $500,000.00 and above. * Special $10,000,000.00 Loan offer for huge project also available. * Loan period of 6 months -- 10 years. * Loan is granted 24 hours after approval and accredited, directly in hand or bank account. Please note that you are advised to contact us for more details via the following e-mail address below; EMAIL : sunrisefundinglt...@gmail.com FIRM : Sunrise Funding Ltd UK.
Re: [PATCH v3 1/3] x86/boot: Introduce the kernel_info
On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote: > Hi, > > Questions and comments below... > Thanks. > > On 10/9/19 3:53 AM, Daniel Kiper wrote: > > > Suggested-by: H. Peter Anvin > > Signed-off-by: Daniel Kiper > > Reviewed-by: Konrad Rzeszutek Wilk > > Reviewed-by: Ross Philipson > > --- > > > --- > > Documentation/x86/boot.rst | 121 > > + > > arch/x86/boot/Makefile | 2 +- > > arch/x86/boot/compressed/Makefile | 4 +- > > arch/x86/boot/compressed/kernel_info.S | 17 + > > arch/x86/boot/header.S | 1 + > > arch/x86/boot/tools/build.c| 5 ++ > > arch/x86/include/uapi/asm/bootparam.h | 1 + > > 7 files changed, 148 insertions(+), 3 deletions(-) > > create mode 100644 arch/x86/boot/compressed/kernel_info.S > > > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > > index 08a2f100c0e6..d5323a39f5e3 100644 > > --- a/Documentation/x86/boot.rst > > +++ b/Documentation/x86/boot.rst > > @@ -68,8 +68,25 @@ Protocol 2.12(Kernel 3.8) Added the xloadflags field > > and extension fields > > Protocol 2.13 (Kernel 3.14) Support 32- and 64-bit flags being set in > > xloadflags to support booting a 64-bit kernel from 32-bit > > EFI > > + > > +Protocol 2.14: BURNT BY INCORRECT COMMIT > > ae7e1238e68f2a472a125673ab506d49158c1889 > > + (x86/boot: Add ACPI RSDP address to setup_header) > > + DO NOT USE!!! ASSUME SAME AS 2.13. > > + > > +Protocol 2.15: (Kernel 5.5) Added the kernel_info. > > = > > > > > > +.. note:: > > + The protocol version number should be changed only if the setup header > > + is changed. There is no need to update the version number if > > boot_params > > + or kernel_info are changed. Additionally, it is recommended to use > > + xloadflags (in this case the protocol version number should not be > > + updated either) or kernel_info to communicate supported Linux kernel > > + features to the boot loader. Due to very limited space available in > > + the original setup header every update to it should be considered > > + with great care. Starting from the protocol 2.15 the primary way to > > + communicate things to the boot loader is the kernel_info. > > + > > > > Memory Layout > > = > > @@ -207,6 +224,7 @@ Offset/Size Proto Name > > Meaning > > 0258/8 2.10+ pref_addressPreferred > > loading address > > 0260/4 2.10+ init_size Linear memory > > required during initialization > > 0264/4 2.11+ handover_offset Offset of > > handover entry point > > +0268/4 2.15+ kernel_info_offset Offset of the > > kernel_info > > ==== > > > > > > .. note:: > > @@ -855,6 +873,109 @@ Offset/size: 0x264/4 > > > >See EFI HANDOVER PROTOCOL below for more details. > > > > + == > > +Field name:kernel_info_offset > > +Type: read > > +Offset/size: 0x268/4 > > +Protocol: 2.15+ > > + == > > + > > + This field is the offset from the beginning of the kernel image to the > > + kernel_info. It is embedded in the Linux image in the uncompressed > ^^ >What does It refer to, please? s/It/The kernel_info structure/ Is it better? > > + protected mode region. > > + > > + > > +The kernel_info > > +=== > > + > > +The relationships between the headers are analogous to the various data > > +sections: > > + > > + setup_header = .data > > + boot_params/setup_data = .bss > > + > > +What is missing from the above list? That's right: > > + > > + kernel_info = .rodata > > + > > +We have been (ab)using .data for things that could go into .rodata or .bss > > for > > +a long time, for lack of alternatives and -- especially early on -- > > inertia. > > +Also, the BIOS stub is responsible for creating boot_params, so it isn't > > +available to a BIOS-based loader (setup_data is, though). > > + > > +setup_header is permanently limited to 144 bytes due to the reach of the > > +2-byte jump field, which doubles as a length field for the structure, > > combined > > +with the size of the "hole" in struct boot_params that a protected-mode > > loader > > +or the BIOS stub has to copy it into. It is currently 119 bytes long, which > > +leaves us with 25 very precious bytes. This isn't something that can be > > fixed > > +without revising the boot protocol entirely, breaking backwards > > compatibility. > > + > > +boot_params proper is limited to 4096 bytes, but can be arbitrarily > > extended > > +by adding setup_d
Re: [PATCH v6 07/12] x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP
On Thu, 10 Oct 2019 at 01:19, Dan Williams wrote:
>
> Given that EFI_MEMORY_SP is platform BIOS policy decision for marking
> memory ranges as "reserved for a specific purpose" there will inevitably
> be scenarios where the BIOS omits the attribute in situations where it
> is desired. Unlike other attributes if the OS wants to reserve this
> memory from the kernel the reservation needs to happen early in init. So
> early, in fact, that it needs to happen before e820__memblock_setup()
> which is a pre-requisite for efi_fake_memmap() that wants to allocate
> memory for the updated table.
>
> Introduce an x86 specific efi_fake_memmap_early() that can search for
> attempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 table
> accordingly.
>
> The KASLR code that scans the command line looking for user-directed
> memory reservations also needs to be updated to consider
> "efi_fake_mem=nn@ss:0x4" requests.
>
> Cc:
> Cc: Borislav Petkov
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Ard Biesheuvel
> Reviewed-by: Dave Hansen
> Signed-off-by: Dan Williams
Acked-by: Ard Biesheuvel
> ---
> Documentation/admin-guide/kernel-parameters.txt | 10 +++
> arch/x86/boot/compressed/kaslr.c| 42 --
> arch/x86/include/asm/efi.h |8 +++
> arch/x86/platform/efi/efi.c |2 +
> drivers/firmware/efi/Makefile |5 +-
> drivers/firmware/efi/fake_mem.c | 24
> drivers/firmware/efi/fake_mem.h | 10 +++
> drivers/firmware/efi/x86_fake_mem.c | 69
> +++
> 8 files changed, 147 insertions(+), 23 deletions(-)
> create mode 100644 drivers/firmware/efi/fake_mem.h
> create mode 100644 drivers/firmware/efi/x86_fake_mem.c
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 47478a730011..9489d76b0e9f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1196,15 +1196,21 @@
> updating original EFI memory map.
> Region of memory which aa attribute is added to is
> from ss to ss+nn.
> +
> If efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1
> is specified, EFI_MEMORY_MORE_RELIABLE(0x1)
> attribute is added to range 0x1-0x18000
> and
> 0x10a000-0x112000.
>
> + If efi_fake_mem=8G@9G:0x4 is specified, the
> + EFI_MEMORY_SP(0x4) attribute is added to
> + range 0x24000-0x43fff.
> +
> Using this parameter you can do debugging of EFI
> memmap
> - related feature. For example, you can do debugging of
> + related features. For example, you can do debugging of
> Address Range Mirroring feature even if your box
> - doesn't support it.
> + doesn't support it, or mark specific memory as
> + "soft reserved".
>
> efivar_ssdt=[EFI; X86] Name of an EFI variable that contains an
> SSDT
> that is to be dynamically loaded by Linux. If there
> are
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index ff6fa81949cd..da0eedd5635d 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -132,8 +132,14 @@ char *skip_spaces(const char *str)
> #include "../../../../lib/ctype.c"
> #include "../../../../lib/cmdline.c"
>
> +enum parse_mode {
> + PARSE_MEMMAP,
> + PARSE_EFI,
> +};
> +
> static int
> -parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
> +parse_memmap(char *p, unsigned long long *start, unsigned long long *size,
> + enum parse_mode mode)
> {
> char *oldp;
>
> @@ -156,8 +162,29 @@ parse_memmap(char *p, unsigned long long *start,
> unsigned long long *size)
> *start = memparse(p + 1, &p);
> return 0;
> case '@':
> - /* memmap=nn@ss specifies usable region, should be skipped */
> - *size = 0;
> + if (mode == PARSE_MEMMAP) {
> + /*
> +* memmap=nn@ss specifies usable region, should
> +* be skipped
> +*/
> + *size = 0;
> + } else {
> + unsigned long long flags;
> +
> + /*
> +* efi_fake_mem=nn@ss:attr the attr specifies
> +* flags that might imply a soft-reservation.
> +*/
> +
