Make pmtimer tsc calibration not take 51 seconds to fail.
On my laptop running at 2.4GHz, if I run a VM where tsc calibration
using pmtimer will fail presuming a broken pmtimer, it takes ~51 seconds
to do so (as measured with the stopwatch on my phone), with a tsc delta
of 0x1cd1c85300, or around 125 billion cycles.
If instead of trying to wait for 5-200ms to show up on the pmtimer, we try
to wait for 5-200us, it decides it's broken in ~0x2626aa0 TSCs, aka ~2.4
million cycles, or more or less instantly.
Additionally, this reading the pmtimer was returning 0xffffffff anyway,
and that's obviously an invalid return. I've added a check for that and
0 so we don't bother waiting for the test if what we're seeing is dead
pins with no response at all.
If "debug" is includes "pmtimer", you will see one of the following
three outcomes. If pmtimer gives all 0 or all 1 bits, you will see:
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware and
these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer gives any other bit patterns but is not actually marching
forward fast enough to use for clock calibration, you will see:
kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations)
kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0
This outcome was tested using grub compiled with GRUB_PMTIMER_IGNORE_BAD_READS
defined (so as not to trip the bad read test) using qemu+kvm with UEFI
(OVMF) firmware, and these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer actually works, you'll see something like:
kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations)
kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware, and
these options: -machine pc-i440fx-2.4 -cpu Broadwell-noTSX
This adds "exit" with a return code. With this patch, any "exit"
command /may/ include a return code, and on platforms that support
returning with an exit status, we will do so. By default we return the
same exit status we did before this patch.
Signed-off-by: Peter Jones <email address hidden>
(cherry picked from commit ccce3d69ae3eacc7bdc70217304586bd7e74fe1e)
Patch-Name: rhboot-f34-make-exit-take-a-return-code.patch
(cherry picked from commit f58cd1f3cf1cf8bf3ee5f57ae035a14888840448)
(cherry picked from commit eaa54045462a9993e2df8613ac7117760bbd5220)
cfdb9b2...
by
Javier Martinez Canillas <email address hidden>
tftp: Roll-over block counter to prevent data packets timeouts
Commit 781b3e5efc3 (tftp: Do not use priority queue) caused a regression
when fetching files over TFTP whose size is bigger than 65535 * block size.
It is caused by the block number counter being a 16-bit field, which leads
to a maximum file size of ((1 << 16) - 1) * block size. Because GRUB sets
the block size to 1024 octets (by using the TFTP Blocksize Option from RFC
2348 [0]), the maximum file size that can be transferred is 67107840 bytes.
The TFTP PROTOCOL (REVISION 2) RFC 1350 [1] does not mention what a client
should do when a file size is bigger than the maximum, but most TFTP hosts
support the block number counter to be rolled over. That is, acking a data
packet with a block number of 0 is taken as if the 65356th block was acked.
It was working before because the block counter roll-over was happening due
an overflow. But that got fixed by the mentioned commit, which led to the
regression when attempting to fetch files larger than the maximum size.
To allow TFTP file transfers of unlimited size again, re-introduce a block
counter roll-over so the data packets are acked preventing the timeouts.
Fixes: 781b3e5efc3 (tftp: Do not use priority queue)
Suggested-by: Peter Jones <email address hidden>
Signed-off-by: Javier Martinez Canillas <email address hidden>
Reviewed-by: Daniel Kiper <email address hidden>
eb6666c...
by
Javier Martinez Canillas <email address hidden>
efi: Set image base address before jumping to the PE/COFF entry point
Upstream GRUB uses the EFI LoadImage() and StartImage() to boot the Linux
kernel. But our custom EFI loader that supports Secure Boot instead uses
the EFI handover protocol (for x86) or jumping directly to the PE/COFF
entry point (for aarch64).
This is done to allow the bootloader to verify the images using the shim
lock protocol to avoid booting untrusted binaries.
Since the bootloader loads the kernel from the boot media instead of using
LoadImage(), it is responsible to set the Loaded Image base address before
booting the kernel.
Otherwise the kernel EFI stub will complain that it was not set correctly
and print the following warning message:
EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
Resolves: rhbz#1825411
Signed-off-by: Javier Martinez Canillas <email address hidden>
[ dannf: Offset adjustment to apply to Ubuntu's GRUB ]
Cherry-pick back parts of "Load arm with SB enabled."
These parts got lost in our 2.04 rebase, let's add them back.
Pick (grub_efi_physical_address_t)(grub_efi_uintn_t) cast from
fedora-34 instead, it seems to cause compilation error on armhf
to not do the (grub_efi_uintn_t) cast first.
