| Age | Commit message (Collapse) | Author |
|---|
|
Over years number of upstream drivers have grown for AMD/Xilinx SOCs
(ZynqMP, Versal, Versal NET) but they are not enabled by default in
defconfig that's why enable all drivers for these SOCs including USB5744
on board USB hub available on Kria ZynqMP based SOMs and Carrier Cards.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/457c3a128e300241afd20da693d1d80a35d1ece6.1758099050.git.michal.simek@amd.com
|
|
Since the following commit, the zynqmp clk driver uses the common
divider_round_rate() when determining the appropriate clock divider for a
requested clock frequency:
https://github.com/torvalds/linux/commit/1fe15be1fb613534ecbac5f8c3f8744f757d237d
This means that all the calculations will be in kHz when determining the
appropriate clock divider for a given cpufreq request. The problem with this
is that the zynqmp.dtsi and zynqmp-clk-ccf.dtsi files have frequency
definitions in Hz, so when dividing requested values in kHz, errors can occur
with the rounding.
For example, the current pss_ref_clk frequency is 33333333 Hz which generates
a cpufreq parent clock frequency of 1199999988 Hz which is the same as the
highest opp-table-cpu frequency in the zynqmp.dtsi.
But if a user requests the value 1199999 kHz as recommended in the available
frequencies:
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
299999 399999 599999 1199999
root@zynqmp:/ # echo 1199999 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
The calculation will be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
Also, if a user tries to work around this calculation by using any larger
values, it still will not fix the problem because the driver will use the
largest opp in kHz which leads to the same calculation error.
User requests 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
Driver converts any value greater than 1199999 to the largest opp which is
1199999 and then calculates the divider value with the same calculation.
The calculation will still be:
1199999988 / 1199999000 = 1.000001
This will get rounded up to a divider value of 2 giving the following result.
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
599999
This means there is no way to configure the zynqmp for the fastest opp using
the current dtsi files.
To fix this issue, this patch updates the zynqmp opp-table-cpu and
pss_ref_clk, so the clock rates are calculated correctly.
root@zynqmp:/sys/kernel/tracing# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
300000 400000 600000 1200000
root@zynqmp:/ # echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
root@zynqmp:/ # cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
1200000
Signed-off-by: Neal Frager <neal.frager@amd.com>
Acked-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251111070555.1169130-1-neal.frager@amd.com
|
|
Unlike zynq, which has a specific compatible for the Cadence spi
controller, zynqmp and versal-net do not have specific compatibles.
In order to "encourage" people to use soc-specific compatibles for new
devices using this IP, add specific compatibles for these devices, with
a fallback to the existing compatible for the r1p6 version of the IP so
that there will be no functional change.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20251001-cheesy-shucking-c55431bbcae3@spud
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The buffer provided to kernel_neon_begin() is only used if the task is
scheduled out while the FP/SIMD is in use by the kernel, or when such a
section is interrupted by a softirq that also uses the FP/SIMD.
IOW, this happens rarely, and even if it happened often, there is still
no reason for this buffer to be cleared beforehand, which happens
unconditionally, due to the use of a compound literal expression.
So define that buffer variable explicitly, and mark it as
__uninitialized so that it will not get cleared, even when
-ftrivial-auto-var-init is in effect.
This requires some preprocessor gymnastics, due to the fact that the
variable must be defined throughout the entire guarded scope, and the
expression
({ struct user_fpsimd_state __uninitialized st; &st; })
is problematic in that regard, even though the compilers seem to
permit it. So instead, repeat the 'for ()' trick that is also used in
the implementation of the guarded scope helpers.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Fixes: 4fa617cc6851 ("arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack")
Link: https://lore.kernel.org/r/20251209054848.998878-2-ardb@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
The logic to fallback to the return address (RA) register value in
the topmost frame when stack tracing using back chain is broken in
multiple ways:
When assuming the RA register 14 has not been saved yet one must assume
that a new user stack frame has not been allocated either. Therefore
the back chain would not contain the stack pointer (SP) at entry, but
the caller's SP at its entry instead.
Therefore when falling back to the RA register 14 value it would also be
necessary to fallback to the SP register 15 value. Otherwise an invalid
combination of RA register 14 and caller's SP at its entry (from the
back chain) is used.
In the topmost frame the back chain contains either the caller's SP at
its entry (before having allocated a new stack frame in the prologue),
the SP at entry (after having allocated a new stack frame), or an
uninitialized value (during static/dynamic stack allocation). In both
cases where the back chain is valid either the caller or prologue must
have saved its respective RA to the respective frame. Therefore, if the
RA obtained from the frame pointed to by the back chain is invalid, this
does not indicate that the IP in the topmost frame is still early in the
prologue and the RA has not been saved.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
When checking `arch/s390/pci/pci.c` with `sparse` during build, the
following complaint is reported:
arch/s390/pci/pci.c: note: in included file (through include/linux/smp.h, include/linux/lockdep.h, include/linux/spinlock.h, include/linux/mmzone.h, include/linux/gfp.h, include/linux/slab.h):
./include/linux/list.h:237:25: warning: context imbalance in 'zpci_release_device' - unexpected unlock
But this is expected, as zpci_release_device() is expected to be called
with `zpci_list_lock` held, as part of `kref_put_lock()` or similar.
Reflect this by annotating the function with the appropriate
__releases().
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
When triggering PCI device recovery by writing into the SysFS attribute
`recover` of a Physical Function with existing child SR-IOV Virtual
Functions, lockdep is reporting a possible deadlock between three
threads:
Thread (A) Thread (B) Thread (C)
| | |
recover_store() zpci_scan_devices() zpci_scan_devices()
lock(pci_rescan_remove_lock) | |
| | |
| | zpci_bus_scan_busses()
| | lock(zbus_list_lock)
| zpci_add_device() |
| lock(zpci_add_remove_lock) |
| | ┴
| | zpci_bus_scan_bus()
| | lock(pci_rescan_remove_lock)
┴ |
zpci_zdev_put() |
lock(zpci_add_remove_lock) |
┴
zpci_bus_get()
lock(zbus_list_lock)
In zpci_bus_scan_busses() the `zbus_list_lock` is taken for the whole
duration of the function, which also includes taking
`pci_rescan_remove_lock`, among other things. But `zbus_list_lock` only
really needs to protect the modification of the global registration
`zbus_list`, it can be dropped while the functions within the list
iteration run; this way we break the cycle above.
Break up zpci_bus_scan_busses() into an "iterator" zpci_bus_get_next()
that iterates over `zbus_list` element by element, and acquires and
releases `zbus_list_lock` as necessary, but never keep holding it.
References to `zpci_bus` objects are also acquired and released.
The reference counting on `zpci_bus` objects is also changed so that all
put() and get() operations are done under the protection of
`zbus_list_lock`, and if the operation results in a modification of
`zpci_bus_list`, this modification is done in the same critical section
(apart the very first initialization). This way objects are never seen
on the list that are about to be released and/or half-initialized.
Fixes: 14c87ba8123a ("s390/pci: separate zbus registration from scanning")
Suggested-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
With z16 a new flag 'search boot program' was introduced for
list-directed IPL (SCSI, NVMe, ECKD DASD). If this flag is set,
e.g. via selecting the "Automatic" value for the "Boot program
selector" control on an HMC load panel, it is copied to the reipl
structure from the initial ipl structure. When a user now sets a
boot prog via sysfs, the flag is not cleared and the bootloader
will again automatically select the boot program, ignoring user
configuration.
To avoid that, clear the SBP flag when a bootprog sysfs file is
written.
Cc: stable@vger.kernel.org
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
Besides formatting changes, this logic dates back to Linux 2.4.0-test11 in
November 2000.
Prior to "Massive cleanup of CPU detection and bug handling",
c->x86_capability was a single u32 containing cpuid(1).edx,
cpuid(0x80000001).edx, or a synthesis thereof. X86_FEATURE_AMD3D was
defined as the top bit this single u32.
After "Massive cleanup of CPU detection and bug handling",
c->x86_capability became an array with AMD's extended feature leaf split
away from Intel's basic feature leaf.
AMD doc #20734-G states that 3DNow is only enumerated in the extended
feature leaf, and that other vendors where using this bit too. i.e. AMD
never produced a CPU which set bit 31 in the basic leaf, meaning that
there's nothing to clear out in the first place.
This logic looks like it was relevant in the pre-"Massive cleanup" world
but ought to have been dropped when c->x86_capability was properly split.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Pu Wen <puwen@hygon.cn>
Link: https://patch.msgid.link/20251126125147.880275-1-andrew.cooper3@citrix.com
|
|
... to simplify the result.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20251126113442.877024-1-andrew.cooper3@citrix.com
|
|
The good revisions are tied to exact steppings, meaning it's not valid to
match on model number alone, let alone a range.
This is probably only a latent issue. From public microcode archives, the
following CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the
model ranges. They're likely pre-production steppings, and likely didn't get
Zenbleed microcode, but it's still incorrect to compare them to a different
steppings revision.
Either way, convert the logic to use x86_match_min_microcode_rev(), which is
the preferred mechanism.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: x86@kernel.org
Link: https://patch.msgid.link/20251126130352.880424-1-andrew.cooper3@citrix.com
|
|
The property is not specified by the binding, nor used by the driver.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Changing the compatible changes the properties allowed -
snps,dw-apb-uart doesn't specify no-loopback-test, so remove it.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
There's neither a binding defined nor a driver that matches on the
compatible, so drop it from the devicetree until someone is motivated to
solve the problems.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Its presence is not required by the binding, its addition was not
discussed in commit aac82707fa45 ("ARM: dts: aspeed: Add AST2600 EDAC
into common devicetree"), and its inconsistent with the g4 and g5
dtsis.
Further, the corresponding driver instantiates its own regmap rather
than fetching the syscon regmap, in theory breaking any users of the
syscon, but of which there appear to be none in-tree.
Drop it for now, and we can add it back with the necessary rework if
it's ever required.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
While sdhci-pltfm supports sdhci,wp-inverted, it also supports
the un-prefixed and specified wp-inverted property. Switch the EVB
devicetree to use the specified property to remove warnings when
checking the DTB.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The property isn't specified in the bindings and is not used by the
corresponding driver, so drop it.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The NVIDIA MSX4 HPM (host platform module) is a reference board for
managing up to 8 PCIe connected NVIDIA GPUs via ConnectX-8 (CX8)
SuperNICs. The BMC manages all GPUs and CX8s for both telemetry and
firmware update via MCTP over USB. The host CPUs are dual socket Intel
Granite Rapids processors.
For more detail on this architecture:
https://developer.nvidia.com/blog/nvidia-connectx-8-supernics-advance-ai-platform-architecture-with-pcie-gen6-connectivity/
Signed-off-by: Marc Olberding <molberding@nvidia.com>
Link: https://patch.msgid.link/20251126-msx1_devicetree-v5-2-e508d13e2dda@nvidia.com
[arj: Reflow text to wrap at limit, whitespace, grammar]
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The gpio-leds driver requires all GPIOs in a group to be available;
if any GPIO in the group is not available the whole group will not be
created. The hdd_led GPIO is only present after standby power is
enabled, which can prevent other LEDs in the same group from being
created and blocks properly setting 'bmc_ready_noled'.
Move the 'hdd_led' node into a separate gpio-leds group so that other
LEDs are not blocked and the 'bmc_ready_noled' flag can be set
correctly.
Fixes: b5dd16228216 ("ARM: dts: aspeed: clemente: Add HDD LED GPIO")
Signed-off-by: Alex Wang <alex.ts.wang@fii-foxconn.com>
Link: https://patch.msgid.link/20251127-leo-dts-add-shunt-resistor-v2-1-c77dfbfb826c@fii-foxconn.com
[arj: Fix patch subject, add Fixes: tag]
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
The chassis power cycle process requires a forced shutdown before
cutting off the standby power. The SCM CPLD implements a hard shutdown
host function that is controlled through the IO expander in the
Clemente platform.
This change adds a new GPIO line named "shdn_force_l_cpld" to the
PCA9555 IO expander's gpio-line-names at index 10. When asserted,
this GPIO signals the CPLD to pull the HPM's SHDN_FORCE_L pin low,
which triggers a forced host shutdown.
Signed-off-by: Kimi Chen <kimi.zy.chen@fii-foxconn.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Add an IPMB node for OCP debug card to support IPMI communication.
Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Add IO expander emulated by the switch board CPLD to handle UART and SPI
mux control signals. Also add SGPIO labels with FM_MODULE_PWR_EN_N_*
signals, which control power to each ASIC module individually.
Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Add EEPROM devices on the I2C buses used for the boot and data NVMe
drives. These EEPROMs store FRU information for each drive, allowing
the BMC to identify.
Signed-off-by: Leo Wang <leo.jt.wang@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Add the SGPIO definition for detecting fanboard presence on the Harma
platform. This allows the BMC to determine whether the fanboard is
attached.
Signed-off-by: Daniel Hsu <Daniel-Hsu@quantatw.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Remove the external signal configuration from wdt1 to prevent the
WDTRST1 pin from being asserted during watchdog resets.
The WDTRST1 pin was originally configured to reset the TPM during
watchdog events. However, the pin is incorrectly routed to SRST#
on the hardware, causing unintended system resets. Since the TPM
is not currently utilized on this platform, remove the external
signal configuration to avoid the incorrect reset behavior.
Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
|
|
Use the human-readable SZ_* constants.
Suggested-by: Nikolay Borisov <nik.borisov@suse.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/92a15c2d-055c-4f4e-b232-32030a8e5e54@suse.com
|
|
The current implementation of e820_search_gap() searches gaps
in a reverse search from MAX_GAP_END back to 0, contrary to
what its main comment claims:
* Search for a gap in the E820 memory space from 0 to MAX_GAP_END (4GB).
But gaps can not only be beyond E820 RAM ranges, they can be below
them as well. For example this function will not find the proper
PCI gap for simplified memory map layouts that have a single RAM
range that crosses the 4GB boundary.
Rework the function to have a proper forward search of
E820 table entries.
This makes the code somewhat bigger:
text data bss dec hex filename
7613 44072 0 51685 c9e5 e820.o.before
7645 44072 0 51717 ca05 e820.o.after
but it now both implements what it claims to do, and is more
straightforward to read.
( This also allows 'idx' to be the regular u32 again, not an 'int'
underflowing to -1. )
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-29-mingo@kernel.org
|
|
Right now e820__range_remove() has two parameters to control the
E820 type of the range removed:
extern void e820__range_remove(u64 start, u64 size, enum e820_type old_type, bool check_type);
Since E820 types start at 1, zero has a natural meaning of 'no type.
Consolidate the (old_type,check_type) parameters into a single (filter_type)
parameter:
extern void e820__range_remove(u64 start, u64 size, enum e820_type filter_type);
Note that both e820__mapped_raw_any() and e820__mapped_any()
already have such semantics for their 'type' parameter, although
it's currently not used with '0' by in-kernel code.
Also, the __e820__mapped_all() internal helper already has such
semantics implemented as well, and the e820__get_entry_type() API
uses the '0' type to such effect.
This simplifies not just e820__range_remove(), and synchronizes its
use of type filters with other E820 API functions, but simplifies
usage sites as well, such as parse_memmap_one(), beyond the reduction
of the number of parameters:
- else if (from)
- e820__range_remove(start_at, mem_size, from, 1);
else
- e820__range_remove(start_at, mem_size, 0, 0);
+ e820__range_remove(start_at, mem_size, from);
The generated code gets smaller as well:
add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-66 (-66)
Function old new delta
parse_memopt 112 107 -5
efi_init 1048 1039 -9
setup_arch 2719 2709 -10
e820__range_remove 283 273 -10
parse_memmap_opt 559 527 -32
Total: Before=22,675,600, After=22,675,534, chg -0.00%
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-28-mingo@kernel.org
|
|
None of the usage sites make use of the 'real_removed_size'
return parameter of e820__range_remove(), and it's hard
to contemplate much constructive use: E820 maps can have
holes, and removing a fixed range may result in removal
of any number of bytes from 0 to the requested size.
So remove this pointless calculation. This simplifies
the function a bit:
text data bss dec hex filename
7645 44072 0 51717 ca05 e820.o.before
7597 44072 0 51669 c9d5 e820.o.after
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-27-mingo@kernel.org
|
|
single-entry tables
So append_e820_table() begins with this weird condition that checks 'nr_entries':
static int __init append_e820_table(struct boot_e820_entry *entries, u32 nr_entries)
{
/* Only one memory region (or negative)? Ignore it */
if (nr_entries < 2)
return -1;
Firstly, 'nr_entries' has been an u32 since 2017 and cannot be negative.
Secondly, there's nothing inherently wrong with single-entry E820 maps,
especially in virtualized environments.
So remove this restriction and remove the __append_e820_table()
indirection.
Also:
- fix/update comments
- remove obsolete comments
This shrinks the generated code a bit as well:
text data bss dec hex filename
7549 44072 0 51621 c9a5 e820.o.before
7533 44072 0 51605 c995 e820.o.after
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-26-mingo@kernel.org
|
|
So the e820.c file has a hodgepodge of __init and __initdata tag
placements:
static int __init e820_search_gap(unsigned long *max_gap_start, unsigned long *max_gap_size)
__init void e820__setup_pci_gap(void)
__init void e820__reallocate_tables(void)
void __init e820__memory_setup_extended(u64 phys_addr, u32 data_len)
void __init e820__register_nosave_regions(unsigned long limit_pfn)
static int __init e820__register_nvs_regions(void)
u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
Standardize on the style used by e820__setup_pci_gap() and place
them before the storage class.
In addition to the consistency, as a bonus this makes the grep output
rather clean looking:
__init void e820__range_remove(u64 start, u64 size, enum e820_type filter_type)
__init void e820__update_table_print(void)
__init static void e820__update_table_kexec(void)
__init static int e820_search_gap(unsigned long *max_gap_start, unsigned long *max_gap_size)
__init void e820__setup_pci_gap(void)
__init void e820__reallocate_tables(void)
__init void e820__memory_setup_extended(u64 phys_addr, u32 data_len)
__init void e820__register_nosave_regions(unsigned long limit_pfn)
__init static int e820__register_nvs_regions(void)
... and if one learns to just ignore the leftmost '__init' noise then
the rest of the line looks just like a regular C function definition.
With the 'mixed' tag placement style the __init tag breaks up the function's
prototype for no good reason.
Do the same for __initdata.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-25-mingo@kernel.org
|
|
Use 'entry_new' to make clear we are allocating a new entry.
Change the table-full message to say that the table is full.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-24-mingo@kernel.org
|
|
e820_search_gap() et al
The PCI gap searching functions pass around pointers to the
gap_start/gap_size variables, which refer to the maximum
size gap found so far.
Rename the variables to say so, and disambiguate their namespace
from 'current gap' variables.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-23-mingo@kernel.org
|
|
PCI gap
Right now the main x86 function that determines the position and size
of the 'PCI gap', e820_search_gap(), has this curious property:
while (--idx >= 0) {
...
if (gap >= *gap_size) {
I.e. it will iterate the E820 table backwards, from its end to the beginning,
and will search for larger and larger gaps in the memory map below 4GB,
until it finishes with the table.
This logic will, should there be two gaps with the same size, pick the
one with the lower physical address - which is contrary to usual
practice that the PCI gap is just below 4GB.
Furthermore, the commit that introduced this weird logic 16 years ago:
3381959da5a0 ("x86: cleanup e820_setup_gap(), add e820_search_gap(), v2")
- if (gap > gapsize) {
+ if (gap >= *gapsize) {
didn't even declare this change, the title says it's a cleanup,
and the changelog declares it as a preparatory refactoring
for a later bugfix:
809d9a8f93bd ("x86/PCI: ACPI based PCI gap calculation")
which bugfix was reverted only 1 day later without much of an
explanation, and was never reintroduced:
58b6e5538460 ("Revert "x86/PCI: ACPI based PCI gap calculation"")
So based on the Git archeology and by the plain reading of the
code I declare this '>=' change an unintended bug and side effect.
Change it to '>' again.
It should not make much of a difference in practice, as the
likelihood of having *two* largest gaps with exactly the same
size are very low outside of weird user-provided memory maps.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-22-mingo@kernel.org
|
|
Apply misc cleanups:
- Use a bit more readable variable names, we haven't run out of
underscore characters in the kernel yet.
- s/0x400000/SZ_4M
- s/1024*1024/SZ_1M
Suggested-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-21-mingo@kernel.org
|
|
__u32 is for UAPI headers, and this definition is the only place
in the kernel-internal E820 code that uses __u32. Change it to u32.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-20-mingo@kernel.org
|
|
So we have 'idx' types of 'int' and 'unsigned int', and sometimes
we assign 'u32' fields such as e820_table::nr_entries to these 'int'
values.
While there's no real risk of overflow with these tables, make it
all cleaner by standardizing on a single type: u32.
This also happens to shrink the code a bit:
text data bss dec hex filename
7745 44072 0 51817 ca69 e820.o.before
7613 44072 0 51685 c9e5 e820.o.after
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-19-mingo@kernel.org
|
|
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-18-mingo@kernel.org
|
|
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-17-mingo@kernel.org
|
|
So __refdata, like __init, is more of a storage class specifier,
so move the attribute in front of the type, not after the variable
name. This also aligns it vertically.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-16-mingo@kernel.org
|
|
- Use 'idx' index variable instead of a weird 'x'
- Make the error message E820-specific
- Group the code a bit better
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-15-mingo@kernel.org
|
|
For E820_TYPE_RESERVED, print:
'reserved' -> 'device reserved'
For E820_TYPE_PRAM and E820_TYPE_PMEM:
'persistent' -> 'persistent RAM'
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-14-mingo@kernel.org
|
|
E820 related resource allocations
So the E820 code has a rather confusing area of code at around
e820__reserve_resources(), which is, by its plain reading,
rather self-contradictory. For example, the comment explaining
e820__reserve_resources() claims:
- '* Mark E820 reserved areas as busy for the resource manager'
By 'E820 reserved areas' one can naively conclude that it's
talking about E820_TYPE_RESERVED areas - while those areas
are treated in exactly the opposite fashion by do_mark_busy():
switch (type) {
case E820_TYPE_RESERVED:
case E820_TYPE_SOFT_RESERVED:
case E820_TYPE_PRAM:
case E820_TYPE_PMEM:
return false;
Ie. E820_TYPE_RESERVED areas are *not* marked busy for the
resource manager, because E820_TYPE_RESERVED areas are
device regions that might eventually be claimed by a device driver.
This type of confusion permeates this whole area of code,
making it exceedingly difficult to read (for me at least).
So untangle it bit by bit:
- Instead of talking about ambiguous 'reserved areas',
talk about 'E820 device address regions' instead,
and 'register'/'lock' them.
- The do_mark_busy() function is a misnomer as well, because despite
its name it 'does' nothing - it only determines what type
of resource handling an E820 type should receive from the
kernel. Rename it to e820_device_region() and negate its
meaning, to avoid the 'busy/reserved' confusion. Because
that's what this code is really about: filtering out
device regions such as E820_TYPE_RESERVED, E820_TYPE_PRAM,
E820_TYPE_PMEM, etc., and allowing them to be claimed
by device drivers later on.
- All other E820 regions (system regions) are registered and
locked early on, before the PCI resource manager does its
search for device BAR addresses, etc.
Also fix this somewhat misleading comment:
/*
* Try to bump up RAM regions to reasonable boundaries, to
* avoid stolen RAM:
*/
and explain that here we register artificial 'gap' resources
at the end of suspiciously sized RAM regions, as heuristics
to try to avoid buggy firmware with undeclared 'stolen RAM' regions:
/*
* Create additional 'gaps' at the end of RAM regions,
* rounding them up to 64k/1MB/64MB boundaries, should
* they be weirdly sized, and register extra, locked
* resource regions for them, to make sure drivers
* won't claim those addresses.
*
* These are basically blind guesses and heuristics to
* avoid resource conflicts with broken firmware that
* doesn't properly list 'stolen RAM' as a system region
* in the E820 map.
*/
Also improve the printout of this extra resource a bit: make the
message more unambiguous, and upgrade it from pr_debug() (where
very few people will see it), to pr_info() (where it will make
it into the syslog on default distro configs).
Also fix spelling and improve comment placement.
No change in functionality intended.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-13-mingo@kernel.org
|
|
early_panic() is a pointless wrapper around panic():
static void __init early_panic(char *msg)
{
early_printk(msg);
panic(msg);
}
panic() will already do a printk() of 'msg', and an early_printk() if
earlyprintk is enabled. There's no need to print it separately.
Remove the function.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-12-mingo@kernel.org
|
|
There's a number of structure fields and local variables related
to E820 entry physical addresses that are defined as 'unsigned long long',
but then are compared to u64 fields.
Make the types all consistently u64.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-11-mingo@kernel.org
|
|
It is a bit weird and inconsistent that the PCI gap is
advertised during bootup as 'mem'ory:
[mem 0xc0000000-0xfed1bfff] available for PCI devices
^^^
It's not really memory, it's a gap that PCI devices can decode
and use and they often do not map it to any memory themselves.
So advertise it for what it is, a gap:
[gap 0xc0000000-0xfed1bfff] available for PCI devices
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-10-mingo@kernel.org
|
|
So it is a bit weird that the actual RAM entries of the E820 table
are not actually called RAM, but 'usable':
BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB usable
'usable' is pretty passive-aggressive in that context and ambiguous,
most E820 entries denote 'usable' address ranges - reserved ranges
may be used by devices, or the platform.
Clarify and disambiguate this by making the boot log entry
explicitly say 'System RAM', like in /proc/iomem:
BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] 1.9 GB System RAM
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/20250515120549.2820541-9-mingo@kernel.org
|
|
e820_print_type()
We are going to add more columns to the E820 table printout,
so make e820_print_type()'s field separator (space character)
part of the function itself.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-7-mingo@kernel.org
|
|
Gaps in the E820 table are not obvious at a glance and can
easily be overlooked.
Print out gaps in the E820 table:
Before:
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable
BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved
BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
After:
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff]
BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable
BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved
BIOS-e820: [gap 0x0000000080000000-0x00000000afffffff]
BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
BIOS-e820: [gap 0x00000000c0000000-0x00000000fed1bfff]
BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
BIOS-e820: [gap 0x00000000fed20000-0x00000000feffbfff]
BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
BIOS-e820: [gap 0x00000000ff000000-0x00000000fffbffff]
BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
BIOS-e820: [gap 0x0000000100000000-0x000000fcffffffff]
BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
Also warn about badly ordered E820 table entries:
BUG: out of order E820 entry!
( this is printed before the entry is printed, so there's no need to
print any additional data with the warning. )
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-6-mingo@kernel.org
|
|
There are no external users of this function left.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20250515120549.2820541-5-mingo@kernel.org
|
