In preparation for handling platform differentiated memory types beyond
persistent memory, uplevel the "region" identifier to a global number
space. This enables a device-dax instance to be registered to any memory
type with guaranteed unique names.
Cc: Keith Busch
Signed-off-by: Dan Williams
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
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
PFN flags are (unsigned long long), fix the alloc_dax_region() calling
convention to fix warnings of the form:
>> include/linux/pfn_t.h:18:17: warning: large integer implicitly truncated to
>> unsigned type [-Woverflow]
#define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))
Cc: Vishal Verma
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
Platform firmware like EFI/ACPI may publish "hmem" platform devices.
Such a device is a performance differentiated memory range likely
reserved for an application specific use case. The driver gives access
to 100% of the capacity via a device-dax mmap instance by default.
However, if
Memory that has been tagged EFI_MEMORY_SP, and has performance
properties described by the ACPI HMAT is expected to have an application
specific consumer.
Those consumers may want 100% of the memory capacity to be reserved from
any usage by the kernel. By default, with this enabling, a platform
In preparation for adding another EFI_MEMMAP dependent call that needs
to occur before e820__memblock_setup() fixup the existing efi calls to
check for EFI_MEMMAP internally. This ends up being cleaner than the
alternative of checking EFI_MEMMAP multiple times in setup_arch().
Cc:
Cc: Ingo
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 intent of this bit is to allow the OS to identify precious
or scarce memory resources and optionally manage it separately from
EfiConventionalMemory. As
In preparation for registering device-dax instances for accessing EFI
specific-purpose memory, arrange for the HMAT registration to occur
later in the init process. Critically HMAT initialization needs to occur
after e820__reserve_resources_late() which is the point at which the
iomem resource
Changes since v5 [1]:
- Move efi=nosoftreserve infrastructure to a common location. (Ard)
- Define a common efi_soft_reserve_enabled() helper for efi
stub code and runtime core efi. (Ard)
- Add ARM support for honoring soft reservations (Ard)
- Rename x86-fake_mem.c to x86_fake_mem.c. (Ard)
Currently hmat.c lives under an "hmat" directory which does not enhance
the description of the file. The initial motivation for giving hmat.c
its own directory was to delineate it as mm functionality in contrast to
ACPI device driver functionality.
As ACPI continues to play an increasing role in
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
>
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
The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of
This field contains maximal allowed type for setup_data.
Now bump the setup_header version in arch/x86/boot/header.S.
Suggested-by: H. Peter Anvin
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Ross Philipson
---
Documentation/x86/boot.rst | 9
Hi,
Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series
On Sat, 5 Oct 2019 at 13:38, Dominik Brodowski
wrote:
>
> Implement the same mechanism for x86 efistub as introduced by commit
> 568bc4e87033 ("efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the
> UEFI RNG table") for efi/arm*/libstub, and best described here and there
> as:
>
> Invoke the
On Wed, 9 Oct 2019 at 04:18, Matthew Garrett wrote:
>
> On Tue, Oct 8, 2019 at 9:55 PM Javier Martinez Canillas
> wrote:
> > Signed-off-by: Javier Martinez Canillas
> > Acked-by: Laszlo Ersek
>
> Acked-by: Matthew Garrett
Thanks all. Queued as a fix.
Hello Narendra,
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
20 matches
Mail list logo
