If there's a kboot.conf, prase it after the command line args are
parsed. It's not always easy to get all the right command line args
depending on the environment. Allow an escape hatch. While we can't do
everything one might like in this file, we can do enough.
Sponsored by: Netflix
We were assuming that hostdisk_override was both a directory and a
file, which is not going to work very well. It's supposed to be a
single file, so recode it as such. Simplify erorr handling a little as
well and fix a return type-mismatch that doesn't matter for the
generated code (return NULL is the same as return false in this
context)
Sponsored by: Netflix
MIN works for any type, while min() is only for integers. So we were
rounding down to 0 since that's the size of 4GB truncated to an int.
Sponsored by: Netflix
When we're running on a FreeBSD host, we can't open /proc/iomem. So,
for now, just assume that we have 32GB of ram starting at 4GB.
Sponsored by: Netflix
Address two issues with current help file logic:
The existing condition prevents the common help file from being
installed when there are no additional help files defined. This results
in no loader.help on EFI platforms, for example.
Second, due to the fact that we build and install multiple loader types,
each successive install will clobber the previous loader.help. The
result is that we could lose type-specific commands, or possibly list
them in loaders that do not have such commands.
Instead, give each loader type a uniquely named help file. The EFI
loader will look for /boot/loader.help.efi, userboot will look for
/boot/loader.help.userboot, etc. The interpreter variant has no effect
on which help file is loaded.
This leaves the old /boot/loader.help unused.
Some credit for the final approach goes to Mathieu <sigsys@gmail.com>
for their version of the fix in https://reviews.freebsd.org/D22951.
PR: 267134
Reported by: Daniel O'Connor <darius@dons.net.au>
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28591
Keep track of how much is used in the segment as we allocate it to the
application. Set memsz to 0 first, and increment it as used. Adjust the
bufsz before we call kexec so the kernel copies the right amount (it's
an error for bufsz to be bigger than memsz, so we set them == when we
retrieve the segment). Make sure we round to the page size, otherwise
kexec_load gets cranky.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38315
Allocate a huge segment for the first kexec_load segments. We limit the
lessor of:
allocation to the size of the remaining memory segment
45% of available memory
95% of the memory we can allocate
This allows us to have really large RAM disks. We likely need to limit
this to the amount we actually used, though, since this can be a lot of
memory.
We have to do this complicated calculation for a few reasons: First, we
need 2 copies of the loaded kernel in the memory: The kernel can copy
everything to a temporary buffer. Next, malloc (via mmap) is limited to
a certain amount due to over commit, so we have to not allocate all we
can (only most of what we can).
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38314
kboot_get_phys_load_segment is defined in kboot.h, so remove them from
the .c files.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38310
Try to open /dev/mem to read in the UEFI memory map. If we can't, then
we'll read it in the trampoline.
Retain reading in /proc/iomem to find reserved areas in Linux. We need
to know them for good places to put the kernel. These are not reflected
in the UEFI memory map. However, we should not adjust the UEFI memory
map since these reserved areas of the Linux kernel are free to be used
once we enter the kexec trampoline...
Sponsored by: Netflix
Reviewed by: tsoome, kevans, andrew
Differential Revision: https://reviews.freebsd.org/D38264
There's no need for an arch pointer to get segments. We can call the
routine directly since we don't need this code to be called from
different context where a pointer is needed.
Sponsored by: Netflix
Reviewed by: kevans, andrew
Differential Revision: https://reviews.freebsd.org/D38266
A number of bug fixes to loading kernels and modules on aarch64 and amd64.
Fix offset calcuations.
Add a number of debugs, commented out for now (will GC them in the future)
With this, and the MD aarch64 commands, we can linux boot in qemu and on
real hardware.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38261
Copy more of the necessary state for FreeBSD to boot:
o Copy EFI memory tables
o Create custom page tables needed for the kernel to find itself
o Simplify the passing of args to the trampoline by putting them
on the stack rather than in dedicated memory.
This is only partially successful... we get only part way through the
amd64 startup code before dying. However, it's much further than before
the changes.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38259
Update exec.c (copyied from efi/loader/arch/arm64/exec.c) to allow
execution of aarch64 kernels. This includes a new trampoline code that
handles copying the UEFI memory map, if available from the Linux FDT
provided PA. This is a complete implementation now, able to boot from
the LinuxBoot environment on an aarch64 server that only offers
LinuxBoot (though a workaround for the gicv3 inability to re-init is not
yet in FreeBSD). Many 'fit and finish' issues will be addressed in
subsequent commits.
Sponsored by: Netflix
Reviewed by: tsoome, kevans, andrew
Differential Revision: https://reviews.freebsd.org/D38258
Connect efi's bootinfo.c to the kboot build, and adjust to use
the kboot specific routines.
The getrootmount() call is independent of EFI. Remove ifdefs so it's
called for kboot too.
The differences between the kboot and efi bootinfo.c files are now tiny.
This could use some more refactoring, but this is a working checkpoint.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38350
Since aarch64 is different, it needs a different smap. We first see if
we have the PA of the table from the FDT info. If so, we copy that and
quit. Otherwise, we do the best we can in translating the /proc/iomap
into EFI Memory Table format.
We also send the system table to the kernel.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38255
Copy the EFI memory tables we were able to get into the MODINFOMD_SMAP
metadata area for the kernel.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38254
It's just a stub, since the kernel learns of memory via FDT.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38253
Each architecture will soon be required to provide this to load memory
maps as metadata for the platforms that require it (or a stub function
for those that don't).
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38252
Now that all architectures provide this, enumerate the platform's memory
before we go to interact(). This needs to be done only once, but relies
on our ability to open host: files on some platforms, so it needs to be
done after devinit().
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38251
Move memory enumeration to the enumerate_memory_arch(), tweak the code a
bit to make that fit into that framework.
Also fix a bug in the name of the end location. The old code never found
memory (though amd64 doesn't yet work, this lead to using fallback
addresses that were good enough for QEMU...).
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38250
We have an odd situation with aarch64 memory enumeration. The fdt that
we can get has a PA of the UEFI memory map, as modified by the current
running Linux kernel so it can retain those pages it needs for EFI and
other services. We have to pass in this EFI tablem but don't have access
to it in the boot loader. We do in the trampoline code, so a forthcoming
commit will copy it there for the kernel to use. All for want of /dev/mem
in the target environment sometimes.
However, we also have to find a place to load the kernel, so we have to
fallback to /proc/iomem when we can't read the UEFI memory map directly
from /dev/mem. It will give us good enough results to do this task. This
table isn't quite suitable to be converted to the EFI table, so we use
both methods. We'll fall back to this method also if there's no EFI
table advertised in the fdt. There's no /sys file on aarch64 that has
this information, hence using the old-style /proc/iomem. We're unlikely
to work if there's no EFI, though.
Note: The underlying Linux mechanism is different than the amd64 method
which seems like it should be MI, but unimplemented on aarch64.
Sponsored by: Netflix
Discussed with: kevans
Differential Revision: https://reviews.freebsd.org/D38249
Add stub for new MI interface for enumerating memory. Right now powerpc
looks in the FDT table at a later point in boot since we don't need to
pass a specific memory table to the kernel. Leave it like that for now,
but note plans for the future.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38248
We'll be using this code for most / all of the platforms since iomem is
the only interface that can tell us of the reserved to the linux kernel
areas that we cannot place the new kernel into, but that we are free to
use once we hit trampoline. aarch64 will use this shortly, and similar
code in amd64 will be refactored when I make that platform work.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38309
Create segment handling code up to the top level. Move it all into
seg.c, and make necessary adjustments for it being in a new file,
including inventing print_avail() and first_avail() to print the array
and find the first large enough memory hole. aarch64 will use this,
and I'll refactor the other platforms to use it as I make them work.
Sponsored by: Netflix
Discussed with: kevans
Differential Revision: https://reviews.freebsd.org/D38308
enumerate_memory_arch is called once early in kboot's startup to allow
us to discover the memory layout, reserved areas, etc of the system
memory. Add the MI interface part of this.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D38247
Guess where to boot from when bootdev= isn't on the command line or
other config. Search all the disks and partitions for one that looks
like it could be a boot partition (same as we do when probing
zpools). Return the first one we find.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38319
Turns out that the loadaddr interface is not sufficiently expressive to
do the loading we need to do. Instead, we'll emulate some of its
features with inline math in copyin/copyout.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38260
When converting from a Linux error to a FreeBSD errno, assert that the
value passed in is negative, as is Linux's custom.
Suggested by: brooks
Sponsored by: Netflix
Reviewed by: tsoome, brooks
Differential Revision: https://reviews.freebsd.org/D38357
To properly size segments, we have to know how much memory we have in
the system, as well as how much this process can allocate. Due to our
inability to overcommit, we need to know how much memory is
available. commit_limit is the grand total allowed. committed_as is the
current memory used. mem_avail is what Linux tells us is available. Find
these from /proc/meminfo. We'll use them later to allocate the biggest
possible segment sizes, but for now print the raw numbers.
Sponsored by: Netflix
Reviewed by: kevans (earlier version)
Differential Revision: https://reviews.freebsd.org/D38267
Translate the Linux error return from read to a FreeBSD errno. We use a
simplified translation: 1-34 are the same between the systems, so any of
those will be returned directly. All other errno map to EINVAL. This
will suffice for some code that reads /dev/mem in producing the right
diagnostic.
A fully generalized version is much harder. Linux has a number of errno
that don't translate well and has architecture dependent
encodings. Avoid this mess with a simple macro for now. Add comment
explaining why we use the simple method we do.
Sponsored by: Netflix
Reviewed by: kevans, andrew
Differential Revision: https://reviews.freebsd.org/D38265
The device name was totally wrong. It should be "/dev/mumble:" not just
"mumble".
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D38318
We only need 64MB to read off ZFS pools. Since Linux doesn't do
ovecommit by default, the extra 64MB is 64MB less we can allocate for
things like RAM disks.
Sponsored by: Netflix
Reviewed by: kevans, andrew
Differential Revision: https://reviews.freebsd.org/D38268
Use the standard set_currdev instead of the (now very old) copy of
setting currdev and loaddev directly. We do this only when we don't go
find the ZFS pool to boot from.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38012
When hostdisk_override is set, all the /dev devices are hidden, and only
the files in that directory are used. This will allow filesystem testing
on FreeBSD without root, for example. Adjust the parse routine to not
require devices start with /dev (plus fix a leak for an error
condition). Add a match routine to allow the device name to be something
like "/home/user/testing/zfsfoo:" instead of strictly in /dev. Note:
since we need to look at all the devices in the system to probe for ZFS
zpools, you can't generally use a full path to get a 'virtual disk' at
this time.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38011
Fetch bootdev from the environment variable (so it should be set on the
command line). Default to 'zfs:' which will in the future look for the
first zpool that we can boot from. Prior versions of kboot would set
this from the second argument on the command line.
Fetch hostfs_root from the environment (defaulting to '/'). Prior
versions of kboot would set this from the first arg on the command line.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38010
Now that all the pieces are in place, allow kboot to be built with ZFS
support.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38009
Add the zfs device and filesystem to config and write the hook we need
to probe zfs since there's not a generic mechanism in place to do that
when ZFS is configured.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38008
Add helper function to walk through the disk drives we've found to look
for zpools. main.c will still need to call this because the loader
hasn't implemented a good way to 'taste' drives for zpools and/or GELI
partitions (mostly because there's no generic list of candidate
devices).
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38007
Keep a list of disks and partitions that we have. Keep track of the
sizes of the media and sector and use that to implement DIOCGMEDIASIZE
and DIOCGSECTORSIZE. Proivde a way to lookup disks by name.
Sponsored by: Netflix
Reviewed by: kevans (prior version)
Differential Revision: https://reviews.freebsd.org/D38013
ZFS uses a lot of memory. The old minimal allocations won't work when
ZFS support is added. Most environments this will be used (or will
liekly be used) have >> 256MB, 128MB should be safe everywhere and allow
examination of a fair number of ZFS pools to boot from.
Sponsored by: Netflix
Add the familiar macros for file types for stat's st_mode
member. Prepend HOST_ to the start of these. Make sure all the values
match the linux nolibc and uapi headers. These values are the same as
native values since they appear to be required by POSIX. Define anyway
to allow the reader of the code to know that they are in the 'host (eg
Linux)' namespace rather than the 'loader' namespace.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37967
Linux pre-boot environments will often have a number of psuedo disks
that are small, all smaller than a few MB. 16MB is a good cutoff since
it's big enough to filter these devices, yet small enough to allow a
super-minimal partition through (the smallest I've been able to make
that's useful lately is around 20MB).
Sponsored by: Netflix
`int foo();` means 'a function that takes any number of arguments.`
not `a function that takes no arguemnts`, that's spelled `int foo(void);`
Adopt the latter.
Sponsored by: Netflix
Linux has /sys/firmware/fdt and /proc/device-tree to publish the dtb for
the system. The former has it all in one file, while the latter breaks
it out. Prefer the former since it's the more modern interface, but
retain both since I don't have a PS3 to test to see if its kernel is new
enough for /sys/firmware or not.
In addition, do the proper fixup.
Sponsored by: Netflix