In the case of a kernel older than 4.17 then MAP_FIXED_NOREPLACE doesn't exist.
This adds a check in to see if the pointer returned was valid but not what we asked for
Instead of forcing a fixed offset for the stack. Allow it to get placed automatically.
64-bit was already doing this; Now we can also do it in 32-bit.
This is possible because the mapper that is mapping the code will always map in the 32-bit space
for a 32-bit guest.
Test sleeps for 1 second and expects to come back within 10ms of the time.
When the CPU is doing other things then it can end up missing that timeframe. Thus flake.
Just disable it
Places them in RO where they can't be modified.
While we're in the area, we can use an alias to prevent duplicated array
types, and also add a static assert to ensure the arrays are always the
same size.
This allows us to avoid needing to bounds check several accesses in a
row that we know will always be successful.
This function does everything required for setting up a squashfs as a rootfs.
- Checks if the file is a valid squashfs
- Executes the FEXMountDaemon
- Error checks to ensure it was mounted correctly
- Updates CONFIG_ROOTFS to point to the mounted location
- Takes 200-400ms more startup time
This is a tool that communicates with FEXLoader/FEXInterpreter to automatically mount
squashfs based rootfs files on execve.
This tool will launch automatically if you have a squashfs based rootfs selected.
Once the rootfs is mounted, it will watch for the parent FEX processe to completely exit.
Once the parent FEX exits it will unmount and cleanup after itself.
This tool has a dependency on your host having FUSE, fusermount, and squashfuse applications.
If anything goes wrong in the bringup process then it propagates the erro up the chain and will
let FEX know that it couldn't mount.
We already have a Config.h which conflicts with this file.
In issue cropped up if you need to include Config.h (the generated one)
from inside Common/ then it would only pull the Common/Config.h file.
Just change the name to not be confusing
Transparent huge pages is a feature that the linux kernel opportunistically uses.
Depending on kernel configuration this feature is either enabled always, or when you madvise the region.
To ensure we hit both cases, madvise the regions we allocate in the 64-bit VMA allocator always
Can reduce kernel bookkeeping memory usage for our abusive allocator
When running the cpuid application (http://www.etallen.com/cpuid.html) I noticed
that we were returning some garbage data here.
After initially implementing support for leaf functions, it still didn't resolve the issue.
So I had to fix those in the x86-64 JIT.
I then went through and solved more issues with the function results.
- We now return a more sane CPU family that is near the feature set we support
- APICID now understands how to fill out the data correctly depending on emulated core counts
- Disabled some CPU features that we don't actually support
- Found two more cache functions that we weren't populating
- Filled with generic data cache size data
- Only thing that matters is that we ensure that cacheline size is reported as 64bytes
- L1D: 32KB, L1I: 32KB, L2: 512KB, L3: 8MB claimed for caches
- Implemented Leafs for functions
- 7h - Only has leaf 0
- Dh - Extended CPU features support
- Another register that lets you claim support for x87, SSE, and AVX
- Leaf 1 & 2 has some additional data
- 4h & 8000'0001Dh - Extended cache properties
- Almost the same as each other. One reports slightly less data though
After FEX has forked, there aren't any other threads in the process but their stacks remain.
We need to have some book keeping in place to have the stack ranges available to clean up
after fork.
We now keep both live stacks and dead stacks in a dequeue and on fork we will walk both to
clean up all stack objects that aren't our current thread.
rsi is a SSA argument, so we need to make sure to move the leaf argument first.
the leaf argument was getting corrupted when moving to the ABI.
Will be necessary once CPUID supports leafs
Passing in the string directly through the format string input can
unintentionally cause the output string to be interpreted as a format
string.
We can specify a separate format string to ensure it always prints
without any potential mangling.
<iostream> injects a static constructor in translation units that
include it, even if its facilities aren't used.
We can make use of <sstream> to avoid needing to execute those on
startup.
Ryan Houdek