IBM NVMeOF Changes #132
Open
IBM NVMeOF Changes #132
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is an example service file, for use from /lib/systemd/system/system-update.target.wants to increment the boot_indeterminate variable when doing offline updates. Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
This lets you write config files that don't know urls. Signed-off-by: Peter Jones <[email protected]>
This lets us have kernel.img be built with TARGET_CFLAGS but grub-mkimage and friends built with HOST_CFLAGS. That in turn lets us build with an ARM compiler that only has hard-float ABI versions of crt*.o and libgcc*, but still use soft float for grub.efi. Signed-off-by: Peter Jones <[email protected]>
…fierxx.c This makes it so you can treat grub-module-verifierxx.c as a file you can build directly, so syntax checkers like vim's "syntastic" plugin, which uses "gcc -x c -fsyntax-only" to build it, will work. One still has to do whatever setup is required to make it pick the right include dirs, which -W options we use, etc., but this makes it so you can do the checking on the file you're editing, rather than on a different file. v2: fix the typo in the #else clause in util/grub-module-verifierXX.c Signed-off-by: Peter Jones <[email protected]>
Trying to avoid all variants of: cat syminfo.lst | sort | gawk -f ../../grub-core/genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1) grub_fdt_install in linux is not defined grub_fdt_load in linux is not defined grub_fdt_unload in linux is not defined grub_fdt_install in xen_boot is not defined grub_fdt_load in xen_boot is not defined grub_fdt_unload in xen_boot is not defined Signed-off-by: Peter Jones <[email protected]> [javierm: Fix build with platform emu, aarch64, and risc-v] Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Robbie Harwood <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
This sets a couple of variables. With the url http://www.example.com/foo/bar : http_path: /foo/bar http_url: http://www.example.com/foo/bar Signed-off-by: Peter Jones <[email protected]> Signed-off-by: Stephen Benjamin <[email protected]> Signed-off-by: Robbie Harwood <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
I'm really tired of half the tools I get to use having one and the other half having the other. Signed-off-by: Peter Jones <[email protected]>
This adds a command that shows you info about grub's version, the grub target platform, the compiler version, and if you built with --with-rpm-version=<string>, the rpm package version. Signed-off-by: Peter Jones <[email protected]> [rharwood: don't say GNU, commit message cleanup] Signed-off-by: Robbie Harwood <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
On mustang, our memory map looks like: Type Physical start - end #Pages Size Attributes reserved 0000004000000000-00000040001fffff 00000200 2MiB UC WC WT WB conv-mem 0000004000200000-0000004393ffffff 00393e00 14654MiB UC WC WT WB ldr-code 0000004394000000-00000043f7ffffff 00064000 1600MiB UC WC WT WB BS-data 00000043f8000000-00000043f801ffff 00000020 128KiB UC WC WT WB conv-mem 00000043f8020000-00000043fa15bfff 0000213c 34032KiB UC WC WT WB ldr-code 00000043fa15c000-00000043fa2a1fff 00000146 1304KiB UC WC WT WB ldr-data 00000043fa2a2000-00000043fa3e8fff 00000147 1308KiB UC WC WT WB conv-mem 00000043fa3e9000-00000043fa3e9fff 00000001 4KiB UC WC WT WB ldr-data 00000043fa3ea000-00000043fa3eafff 00000001 4KiB UC WC WT WB ldr-code 00000043fa3eb000-00000043fa4affff 000000c5 788KiB UC WC WT WB BS-code 00000043fa4b0000-00000043fa59ffff 000000f0 960KiB UC WC WT WB RT-code 00000043fa5a0000-00000043fa5affff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa5b0000-00000043fa5bffff 00000010 64KiB RT UC WC WT WB RT-code 00000043fa5c0000-00000043fa5cffff 00000010 64KiB RT UC WC WT WB ldr-data 00000043fa5d0000-00000043fa5d0fff 00000001 4KiB UC WC WT WB BS-code 00000043fa5d1000-00000043fa5ddfff 0000000d 52KiB UC WC WT WB reserved 00000043fa5de000-00000043fa60ffff 00000032 200KiB UC WC WT WB ACPI-rec 00000043fa610000-00000043fa6affff 000000a0 640KiB UC WC WT WB ACPI-nvs 00000043fa6b0000-00000043fa6bffff 00000010 64KiB UC WC WT WB ACPI-rec 00000043fa6c0000-00000043fa70ffff 00000050 320KiB UC WC WT WB RT-code 00000043fa710000-00000043fa72ffff 00000020 128KiB RT UC WC WT WB RT-data 00000043fa730000-00000043fa78ffff 00000060 384KiB RT UC WC WT WB RT-code 00000043fa790000-00000043fa79ffff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa7a0000-00000043fa99ffff 00000200 2MiB RT UC WC WT WB RT-code 00000043fa9a0000-00000043fa9affff 00000010 64KiB RT UC WC WT WB RT-data 00000043fa9b0000-00000043fa9cffff 00000020 128KiB RT UC WC WT WB BS-code 00000043fa9d0000-00000043fa9d9fff 0000000a 40KiB UC WC WT WB reserved 00000043fa9da000-00000043fa9dbfff 00000002 8KiB UC WC WT WB conv-mem 00000043fa9dc000-00000043fc29dfff 000018c2 25352KiB UC WC WT WB BS-data 00000043fc29e000-00000043fc78afff 000004ed 5044KiB UC WC WT WB conv-mem 00000043fc78b000-00000043fca01fff 00000277 2524KiB UC WC WT WB BS-data 00000043fca02000-00000043fcea3fff 000004a2 4744KiB UC WC WT WB conv-mem 00000043fcea4000-00000043fcea4fff 00000001 4KiB UC WC WT WB BS-data 00000043fcea5000-00000043fd192fff 000002ee 3000KiB UC WC WT WB conv-mem 00000043fd193000-00000043fd2b0fff 0000011e 1144KiB UC WC WT WB BS-data 00000043fd2b1000-00000043ff80ffff 0000255f 38268KiB UC WC WT WB BS-code 00000043ff810000-00000043ff99ffff 00000190 1600KiB UC WC WT WB RT-code 00000043ff9a0000-00000043ff9affff 00000010 64KiB RT UC WC WT WB conv-mem 00000043ff9b0000-00000043ff9bffff 00000010 64KiB UC WC WT WB RT-data 00000043ff9c0000-00000043ff9effff 00000030 192KiB RT UC WC WT WB conv-mem 00000043ff9f0000-00000043ffa05fff 00000016 88KiB UC WC WT WB BS-data 00000043ffa06000-00000043ffffffff 000005fa 6120KiB UC WC WT WB MMIO 0000000010510000-0000000010510fff 00000001 4KiB RT MMIO 0000000010548000-0000000010549fff 00000002 8KiB RT MMIO 0000000017000000-0000000017001fff 00000002 8KiB RT MMIO 000000001c025000-000000001c025fff 00000001 4KiB RT This patch adds a requirement when we're trying to find the base of ram, that the memory we choose is actually /allocatable/ conventional memory, not merely write-combining. On this machine that means we wind up with an allocation around 0x4392XXXXXX, which is a reasonable address. This also changes grub_efi_allocate_pages_real() so that if 0 is allocated, it tries to allocate again starting with the same max address it did the first time, rather than interposing GRUB_EFI_MAX_USABLE_ADDRESS there, so that any per-platform constraints on its given address are maintained. Signed-off-by: Peter Jones <[email protected]>
- Don't limit allocations on 64-bit platforms to < 0x[37f]fffffff if we're using the "large" code model ; use __UINTPTR_MAX__. - Get the comparison right to check the address we've allocated. - Fix the allocation for the command line as well. *But*, when we did this some systems started failing badly; coudln't parse partition tables, etc. What's going on here is the disk controller is silently failing DMAs to addresses above 4GB, so we're trying to parse uninitialized (or HW zeroed) ram when looking for the partition table, etc. So to limit this, we make grub_malloc() pick addresses below 4GB on x86_64, but the direct EFI page allocation functions can get addresses above that. Additionally, we now try to locate kernel+initrd+cmdline+etc below 0x7fffffff, and if they're too big to fit any memory window there, then we try a higher address. Signed-off-by: Peter Jones <[email protected]> [david.abdurachmanov: fix macro for riscv64] Signed-off-by: David Abdurachmanov <[email protected]> Signed-off-by: Robbie Harwood <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
Lots of machines apparently can't DMA correctly above 4GB during UEFI, so use bounce buffers for the initramfs read. Signed-off-by: Peter Jones <[email protected]>
This just helps the next patch be easier to read. Signed-off-by: Peter Jones <[email protected]>
This helps enable allocations above 4GB. Signed-off-by: Peter Jones <[email protected]>
This enables everything except the kernel itself to be above 4GB. Putting the kernel up there still doesn't work, because of the way params->code32_start is used. Signed-off-by: Peter Jones <[email protected]>
This makes the stack executable on most of the grub utilities, which is bad, and rpmdiff complains about it. Signed-off-by: Peter Jones <[email protected]>
Signed-off-by: Peter Jones <[email protected]>
This adds "increment" and "decrement" commands, and uses them to maintain our variables in 01_fallback_counter. It also simplifies the counter logic, so that there are no nested tests that conflict with each other. Apparently, this *really* wasn't tested well enough. Resolves: rhbz#1614637 Signed-off-by: Peter Jones <[email protected]> [lorbus: add comments and revert logic changes in 01_fallback_counting] Signed-off-by: Christian Glombek <[email protected]>
Currently if grub_strtoul(saved_entry_value, NULL, 0) does not return an error, we assume the value it has produced is a correct index into our menu entry list, and do not try to interpret the value as the "id" or "title" . In cases where "id" or "title" start with a numeral, this makes them impossible to use as selection criteria. This patch splits the search into three phases - matching id, matching title, and only once those have been exhausted, trying to interpret the ID as a numeral. In that case, we also require that the entire string is numeric, not merely a string with leading numeric characters. Resolves: rhbz#1640979 Signed-off-by: Peter Jones <[email protected]> [javierm: fix menu entry selection based on title] Signed-off-by: Javier Martinez Canillas <[email protected]>
The --users option is used to restrict the access to specific menu entries
only to a set of users. But the option requires an argument to either be a
constant or a variable that has been set. So for example the following:
menuentry "May be run by superusers or users in $users" --users $users {
linux /vmlinuz
}
Would fail if $users is not defined and grub would discard the menu entry.
Instead, allow the --users option to have an optional argument and ignore
the option if the argument was not set.
Related: rhbz#1652434
Signed-off-by: Javier Martinez Canillas <[email protected]>
This adds "efi-export-env VARIABLE" and "efi-load-env", which manipulate the environment block stored in the EFI variable GRUB_ENV-91376aff-cba6-42be-949d-06fde81128e8. Signed-off-by: Peter Jones <[email protected]>
This makes it so you can do set debug to "all,-scripting,-lexer" and get the obvious outcome. Any negation present will take preference over that conditional, so "all,-scripting,scripting" is the same thing as "all,-scripting". Signed-off-by: Peter Jones <[email protected]>
When a submenu is created, only the exported variables are copied to the new menu context. But we want the variables to be global, so export lets export all variables to the new created submenu. Also, don't unset the default variable when a new submenu is created. Signed-off-by: Javier Martinez Canillas <[email protected]>
Every heap grow will cause all disk caches invalidated which decreases performance severely. This patch moves disk cache invalidation code to the last of memory squeezing measures. So, disk caches are released only when there are no other ways to get free memory. Signed-off-by: Zhang Boyang <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> Reviewed-by: Patrick Steinhardt <[email protected]> (cherry picked from commit 17975d1)
Skip mdraid < 1.1 on isos since mdraid* can't even
Prior to this change, on ppc64le with part_msdos and the mdraid* modules
enabled, we see:
disk/diskfilter.c:191: scanning ieee1275/cdrom
kern/disk.c:196: Opening `ieee1275/cdrom'...
disk/ieee1275/ofdisk.c:477: Opening `cdrom'.
disk/ieee1275/ofdisk.c:502: MAX_RETRIES set to 20
kern/disk.c:288: Opening `ieee1275/cdrom' succeeded.
disk/diskfilter.c:136: Scanning for DISKFILTER devices on disk ieee1275/cdrom
partmap/msdos.c:184: partition 0: flag 0x80, type 0x96, start 0x0, len
0x6a5d70
disk/diskfilter.c:136: Scanning for DISKFILTER devices on disk ieee1275/cdrom
SCSI-DISK: Access beyond end of device !
SCSI-DISK: Access beyond end of device !
SCSI-DISK: Access beyond end of device !
SCSI-DISK: Access beyond end of device !
SCSI-DISK: Access beyond end of device !
disk/ieee1275/ofdisk.c:578: MAX_RETRIES set to 20
These latter two lines repeat many times, eventually ending in:
kern/disk.c:388: ieee1275/cdrom read failed
error: ../../grub-core/disk/ieee1275/ofdisk.c:608:failure reading sector
0x1a9720 from `ieee1275/cdrom'.
and the system drops to a "grub>" prompt.
Prior to 1.1, mdraid stored the superblock offset from the end of the
disk, and the firmware really doesn't like reads there. Best guess was
that the firmware and the iso image appear to diagree on the blocksize
(512 vs. 2048), and the diskfilter RAID probing is too much for it.
It's tempting to just skip probing for cdroms, but unfortunately isos
can be virtualized elsewhere - such as regular disks.
Also fix detection of root, and try the chrp path as a fallback if the
built prefix doesn't work.
Signed-off-by: Robbie Harwood <[email protected]>
wip
These #include lines ensure that grub2 continues to build with C99 where implicit function declarations are removed. Related to: <https://fedoraproject.org/wiki/Changes/PortingToModernC> <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
The GRUB emulator is used as a debugging utility but it could also be used as a user-space bootloader if there is support to boot an operating system. The Linux kernel is already able to (re)boot another kernel via the kexec boot mechanism. So the grub-emu tool could rely on this feature and have linux and initrd commands that are used to pass a kernel, initramfs image and command line parameters to kexec for booting a selected menu entry. By default the systemctl kexec option is used so systemd can shutdown all of the running services before doing a reboot using kexec. But if this is not present, it can fall back to executing the kexec user-space tool directly. The ability to force a kexec-reboot when systemctl kexec fails must only be used in controlled environments to avoid possible filesystem corruption and data loss. Signed-off-by: Raymund Will <[email protected]> Signed-off-by: John Jolly <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Robbie Harwood <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit e364307) [rharwood: conflicts around makefile and grub_exit return code]
Open Hack'Ware was the only user. It added a lot of complexity. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 333e63b)
On PowerVM, the first time we boot a Linux partition, we may only get 256MB of real memory area, even if the partition has more memory. This isn't enough to reliably verify a kernel. Fortunately, the Power Architecture Platform Reference (PAPR) defines a method we can call to ask for more memory: the broad and powerful ibm,client-architecture-support (CAS) method. CAS can do an enormous amount of things on a PAPR platform: as well as asking for memory, you can set the supported processor level, the interrupt controller, hash vs radix mmu, and so on. If: - we are running under what we think is PowerVM (compatible property of / begins with "IBM"), and - the full amount of RMA is less than 512MB (as determined by the reg property of /memory) then call CAS as follows: (refer to the Linux on Power Architecture Reference, LoPAR, which is public, at B.5.2.3): - Use the "any" PVR value and supply 2 option vectors. - Set option vector 1 (PowerPC Server Processor Architecture Level) to "ignore". - Set option vector 2 with default or Linux-like options, including a min-rma-size of 512MB. - Set option vector 3 to request Floating Point, VMX and Decimal Floating point, but don't abort the boot if we can't get them. - Set option vector 4 to request a minimum VP percentage to 1%, which is what Linux requests, and is below the default of 10%. Without this, some systems with very large or very small configurations fail to boot. This will cause a CAS reboot and the partition will restart with 512MB of RMA. Importantly, grub will notice the 512MB and not call CAS again. Notes about the choices of parameters: - A partition can be configured with only 256MB of memory, which would mean this request couldn't be satisfied, but PFW refuses to load with only 256MB of memory, so it's a bit moot. SLOF will run fine with 256MB, but we will never call CAS under qemu/SLOF because /compatible won't begin with "IBM".) - unspecified CAS vectors take on default values. Some of these values might restrict the ability of certain hardware configurations to boot. This is why we need to specify the VP percentage in vector 4, which is in turn why we need to specify vector 3. Finally, we should have enough memory to verify a kernel, and we will reach Linux. One of the first things Linux does while still running under OpenFirmware is to call CAS with a much fuller set of options (including asking for 512MB of memory). Linux includes a much more restrictive set of PVR values and processor support levels, and this CAS invocation will likely induce another reboot. On this reboot grub will again notice the higher RMA, and not call CAS. We will get to Linux again, Linux will call CAS again, but because the values are now set for Linux this will not induce another CAS reboot and we will finally boot all the way to userspace. On all subsequent boots, everything will be configured with 512MB of RMA, so there will be no further CAS reboots from grub. (phyp is super sticky with the RMA size - it persists even on cold boots. So if you've ever booted Linux in a partition, you'll probably never have grub call CAS. It'll only ever fire the first time a partition loads grub, or if you deliberately lower the amount of memory your partition has below 512MB.) Signed-off-by: Daniel Axtens <[email protected]> Signed-off-by: Stefan Berger <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit d5571590b7de61887efac1c298901455697ba307)
This was apparently 'required by some firmware': commit dc94685 ("2007-02-12 Hollis Blanchard <[email protected]>"). It's not clear what firmware that was, and what platform from 14 years ago which exhibited the bug then is still both in use and buggy now. It doesn't cause issues on qemu (mac99 or pseries) or under PFW for Power8. I don't have access to old Mac hardware, but if anyone feels especially strongly we can put it under some feature flag. I really want to disable it under pseries because it will mess with region merging. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit fc639d430297321ee4f77c5d2d698f698cec0dc7)
On powerpc-ieee1275, we are running out of memory trying to verify
anything. This is because:
- we have to load an entire file into memory to verify it. This is
difficult to change with appended signatures.
- We only have 32MB of heap.
- Distro kernels are now often around 30MB.
So we want to be able to claim more memory from OpenFirmware for our heap
at runtime.
There are some complications:
- The grub mm code isn't the only thing that will make claims on
memory from OpenFirmware:
* PFW/SLOF will have claimed some for their own use.
* The ieee1275 loader will try to find other bits of memory that we
haven't claimed to place the kernel and initrd when we go to boot.
* Once we load Linux, it will also try to claim memory. It claims
memory without any reference to /memory/available, it just starts
at min(top of RMO, 768MB) and works down. So we need to avoid this
area. See arch/powerpc/kernel/prom_init.c as of v5.11.
- The smallest amount of memory a ppc64 KVM guest can have is 256MB.
It doesn't work with distro kernels but can work with custom kernels.
We should maintain support for that. (ppc32 can boot with even less,
and we shouldn't break that either.)
- Even if a VM has more memory, the memory OpenFirmware makes available
as Real Memory Area can be restricted. Even with our CAS work, an LPAR
on a PowerVM box is likely to have only 512MB available to OpenFirmware
even if it has many gigabytes of memory allocated.
What should we do?
We don't know in advance how big the kernel and initrd are going to be,
which makes figuring out how much memory we can take a bit tricky.
To figure out how much memory we should leave unused, I looked at:
- an Ubuntu 20.04.1 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~50MB
- a RHEL8.2 ppc64le pseries KVM guest:
vmlinux: ~30MB
initrd: ~30MB
So to give us a little wriggle room, I think we want to leave at least
128MB for the loader to put vmlinux and initrd in memory and leave Linux
with space to satisfy its early allocations.
Allow other space to be allocated at runtime.
Tested-by: Stefan Berger <[email protected]>
Signed-off-by: Daniel Axtens <[email protected]>
(cherry picked from commit a5c710789ccdd27a84ae4a34c7d453bd585e2b66)
[rharwood: _start?]
As a legacy support, if the vector 5 is not implemented, Power Hypervisor will consider the max CPUs as 64 instead 256 currently supported during client-architecture-support negotiation. This patch implements the vector 5 and set the MAX CPUs to 256 while setting the others values to 0 (default). Signed-off-by: Diego Domingos <[email protected]> Acked-by: Daniel Axtens <[email protected]> Signed-off-by: Stefan Berger <[email protected]> Signed-off-by: Avnish Chouhan <[email protected]> (cherry picked from commit 942f19959fe7465fb52a1da39ff271a7ab704892)
Add support for trusted boot using a vTPM 2.0 on the IBM IEEE1275 PowerPC platform. With this patch grub now measures text and binary data into the TPM's PCRs 8 and 9 in the same way as the x86_64 platform does. This patch requires Daniel Axtens's patches for claiming more memory. Note: The tpm_init() function cannot be called from GRUB_MOD_INIT() since it does not find the device nodes upon module initialization and therefore the call to tpm_init() must be deferred to grub_tpm_measure(). For vTPM support to work on PowerVM, system driver levels 1010.30 or 1020.00 are required. Note: Previous versions of firmware levels with the 2hash-ext-log API call have a bug that, once this API call is invoked, has the effect of disabling the vTPM driver under Linux causing an error message to be displayed in the Linux kernel log. Those users will have to update their machines to the firmware levels mentioned above. Cc: Eric Snowberg <[email protected]> Signed-off-by: Stefan Berger <[email protected]> Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 2aa5ef83743dfea79377309ff4f5e9c9a55de355)
Open Hack'Ware was an alternative firmware of powerpc under QEMU. The last commit to any Open Hack'Ware repo I can find is from 2014 [1]. Open Hack'Ware was used for the QEMU "prep" machine type, which was deprecated in QEMU in commit 54c86f5a4844 (hw/ppc: deprecate the machine type 'prep', replaced by '40p') in QEMU v3.1, and had reportedly been broken for years before without anyone noticing. Support was removed in February 2020 by commit b2ce76a0730e (hw/ppc/prep: Remove the deprecated "prep" machine and the OpenHackware BIOS). Open Hack'Ware's limitations require some messy code in GRUB. This complexity is not worth carrying any more. Remove detection of Open Hack'Ware. We will clean up the feature flags in following commits. [1]: https://github.com/qemu/openhackware and https://repo.or.cz/w/openhackware.git are QEMU submodules. They have only small changes on top of OHW v0.4.1, which was imported into QEMU SCM in 2010. I can't find anything resembling an official repo any more. Signed-off-by: Daniel Axtens <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit f9ce538)
The disk sector size provided by sysfs file system considers the sector size of 512 irrespective of disk sector size, thus causing the read by the GRUB to an incorrect offset from what was originally intended. Considering the 512 sector size of sysfs data the actual sector needs to be modified corresponding to disk sector size. Signed-off-by: Mukesh Kumar Chaurasiya <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit f756484)
When grub_memalign() encounters out-of-memory, it will try grub_mm_add_region_fn() to request more memory from system firmware. However, the size passed to it doesn't take region management overhead into account. Adding a memory area of "size" bytes may result in a heap region of less than "size" bytes really available. Thus, the new region may not be adequate for current allocation request, confusing out-of-memory handling code. This patch introduces GRUB_MM_MGMT_OVERHEAD to address the region management overhead (e.g. metadata, padding). The value of this new constant must be large enough to make sure grub_memalign(align, size) always succeeds after a successful call to grub_mm_init_region(addr, size + align + GRUB_MM_MGMT_OVERHEAD), for any given addr and size (assuming no integer overflow). The size passed to grub_mm_add_region_fn() is now correctly adjusted, thus if grub_mm_add_region_fn() succeeded, current allocation request can always succeed. Signed-off-by: Zhang Boyang <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 2282cbf)
When grub_memalign() encounters out-of-memory, it will try grub_mm_add_region_fn() to request more memory from system firmware. However, it doesn't preallocate memory space for future allocation requests. In extreme cases, it requires one call to grub_mm_add_region_fn() for each memory allocation request. This can be very slow. This patch introduces GRUB_MM_HEAP_GROW_EXTRA, the minimal heap growth granularity. The new region size is now set to the bigger one of its original value and GRUB_MM_HEAP_GROW_EXTRA. Thus, it will result in some memory space preallocated if current allocations request is small. The value of GRUB_MM_HEAP_GROW_EXTRA is set to 1MB. If this value is smaller, the cost of small memory allocations will be higher. If this value is larger, more memory will be wasted and it might cause out-of-memory on machines with small amount of RAM. Signed-off-by: Zhang Boyang <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 21869ba)
We do a lot of math about heap growth in hot path of grub_memalign(). However, the result is only used if out of memory is encountered, which is seldom. This patch moves these calculations away from hot path. These calculations are now only done if out of memory is encountered. This change can also help compiler to optimize integer overflow checks away. Signed-off-by: Zhang Boyang <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 65bc459)
Several kernel variants can be installed on a system in parallel. In order to allow the user to choose which kernel will be set to default after an update, re-enable grub's usage of DEFAULTKERNEL as set in /etc/sysconfig/kernel Signed-off-by: Nicolas Frayer <[email protected]>
This patch converts the plain numbers used in Vec5 properties to constants. 1. LPAR: Client program supports logical partitioning and associated hcall()s. 2. SPLPAR: Client program supports the Shared Processor LPAR Option. 3. CMO: Enables the Cooperative Memory Over-commitment Option. 4. MAX_CPU: Defines maximum number of CPUs supported. Signed-off-by: Avnish Chouhan <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 8406cfe)
This patch enables multiple options in Vec5 which are required and
solves the boot issues seen on some machines which are looking for
these specific options.
1. LPAR: Client program supports logical partitioning and
associated hcall()s.
2. SPLPAR: Client program supports the Shared
Processor LPAR Option.
3. DYN_RCON_MEM: Client program supports the
“ibm,dynamic-reconfiguration-memory” property and it may be
presented in the device tree.
4. LARGE_PAGES: Client supports pages larger than 4 KB.
5. DONATE_DCPU_CLS: Client supports donating dedicated processor cycles.
6. PCI_EXP: Client supports PCI Express implementations
utilizing Message Signaled Interrupts (MSIs).
7. CMOC: Enables the Cooperative Memory Over-commitment Option.
8. EXT_CMO: Enables the Extended Cooperative Memory Over-commit Option.
9. ASSOC_REF: Enables “ibm,associativity” and
“ibm,associativity-reference-points” properties.
10. AFFINITY: Enables Platform Resource Reassignment Notification.
11. NUMA: Supports NUMA Distance Lookup Table Option.
12. HOTPLUG_INTRPT: Supports Hotplug Interrupts.
13. HPT_RESIZE: Enable Hash Page Table Resize Option.
14. MAX_CPU: Defines maximum number of CPUs supported.
15. PFO_HWRNG: Supports Random Number Generator.
16. PFO_HW_COMP: Supports Compression Engine.
17. PFO_ENCRYPT: Supports Encryption Engine.
18. SUB_PROCESSORS: Supports Sub-Processors.
19. DY_MEM_V2: Client program supports the “ibm,dynamic-memory-v2” property in the
“ibm,dynamic-reconfiguration-memory” node and it may be presented in the device tree.
20. DRC_INFO: Client program supports the “ibm,drc-info” property definition and it may be
presented in the device tree.
Signed-off-by: Avnish Chouhan <[email protected]>
Reviewed-by: Daniel Kiper <[email protected]>
(cherry picked from commit 98d0df0)
Modify UINT32 to UINTN in EFI_HTTP_MESSAGE to be UEFI 2.9 compliant. Signed-off-by: Keng-Yu Lin <[email protected]> Signed-off-by: Nicolas Frayer <[email protected]>
If GRUB_ENABLE_BLSCFG is true, running grub2-mkconfig will not overwrite kernel cmdline in BLS snippets with what is in GRUB_CMDLINE_LINUX in /etc/default/grub. Update can be forced by sending new arg --update-bls-cmdline, thus decoupling cmdline updates from updates of other parameters. GRUB_GRUBENV_UPDATE remains 'yes' by default. Signed-off-by: mkl <[email protected]>
When the tpm module is loaded, the verifier reads entire file into memory, measures it and uses verified content as a backing buffer for file accesses. However, this process may result in high memory utilization for file operations, sometimes causing a system to run out of memory which may finally lead to boot failure. To address this issue, among others, the commit 887f98f (mm: Allow dynamically requesting additional memory regions) have optimized memory management by dynamically allocating heap space to maximize memory usage and reduce threat of memory exhaustion. But in some cases problems may still arise, e.g., when large ISO images are mounted using loopback or when dealing with embedded systems with limited memory resources. Unfortunately current implementation of the tpm module doesn't allow elimination of the back buffer once it is loaded. Even if the TPM device is not present or it has been explicitly disabled. This may unnecessary allocate a lot memory. To solve this issue, a patch has been developed to detect the TPM status at module load and skip verifier registration if the device is missing or deactivated. This prevents allocation of memory for the back buffer, avoiding wasting memory when no real measure boot functionality is performed. Disabling the TPM device in the system can reduce memory usage in the GRUB. It is useful in scenarios where high memory utilization is a concern and measurements of loaded artifacts are not necessary. Signed-off-by: Michael Chang <[email protected]> Signed-off-by: Stefan Berger <[email protected]> Reviewed-by: Daniel Kiper <[email protected]> (cherry picked from commit 30708df)
This patch enables the fcp-targets and fcp-luns methods which are responsible to get WWPNs and LUNs for fibre channel devices. Those methods are specially necessary if the boot directory and grub installation are in different FCP disks, allowing the dev_iterate() to find the WWPNs and LUNs when called by searchfs.uuid tool. Signed-off-by: Diego Domingos <[email protected]> Signed-off-by: Avnish Chouhan <[email protected]>
Usually grub will parse the PFW arguments by searching for the first occurence of the character ':'. However, we can have this char more than once on NQN. This patch changes the logic to find the last occurence of this char so we can get the proper values for NVMeoFC Signed-off-by: Diego Domingos <[email protected]> Signed-off-by: Avnish Chouhan <[email protected]>
This patch implements the functions to scan and discovery of NVMeoFC. Signed-off-by: Diego Domingos <[email protected]> Signed-off-by: Avnish Chouhan <[email protected]>
This patch add code to enable the translation of logical devices to the of NVMeoFC paths. Signed-off-by: Diego Domingos <[email protected]> Signed-off-by: Avnish Chouhan <[email protected]>
|
Hi RedHat, Any update on the patch reviews? |
|
Hi Avnish, It seems your patches are still not merged upstream. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The following changes will make grub support NVMeOF.