Getting the memory configurations right can become pretty annoying as there are several
different ways the memory can be insufficient and given that some of the "Untyped
Retype: Insufficient memory" emitted are spurious it can quickly become pretty
impossible to debug it all. (There are some pending kernel patches that should remove the
spurious kernel error messages).
The memory requirements for a VM component in the vm_minimal app configuration come from a
series of different constraints:
- The Ram device that gets given to the guest needs to be directly mapped if the guest has
access to any DMA capable devices and there isn't an IOMMU available to support a
virtual-physical address space.
- The VMM needs enough untyped objects to create all of the additional kernel objects
required to support creating the guest. These get used for creating threads, paging
structures, VCPU objects etc.
- In addition, camkes implicitly allocates the untyped objects required for setting up the
VMMs address space and backing data for its code and data program segments.
- All of these objects are initially allocated by the capdl-loader-app which has to be
able to allocate everything from the initial untyped objects that the kernel provides to
it at boot time.
- The kernel creates the initial untypeds based on the static description of Ram it has,
minus any memory that it uses for its own static memory usage.
So when you try and run an app you can see an allocation failure it could be due to:
- There isn't enough memory available in the system for the ELFLoader to load the
kernel and user programs into. The system will crash before the kernel even has a chance
- The kernel doesn't have enough memory available to create the initial objects
required to finish initializing it and the first user task (the capdl-loader-app). The
kernel init would crash at this point.
- Then when the capdl-loader-app runs, the untypeds that it has been given may not be
enough to fit all of the objects that it needs to create into. The loader would print an
error and crash at this point.
- Then once the camkes VM component starts it might run out of memory while trying to
setup the VM if it hasn't been configured properly. Or it might not have been given
the untypeds corresponding to the exact Ram range it requires for creating the
guest's Ram device.
- Then once the guest is started, it may run out of Ram while trying to bring up Linux.
And then Linux will print its own error message (or everything will appear to hang if this
occurs before Linux has started writing to a console).
Debugging these failures requires knowing which memory setting to change based on what
part is failing.
- vm0.simple_untyped24_pool = 12; is the camkes configuration used to give 12 * 2^24
Untyped objects to the vm component. If it is running out of memory while trying to setup
the VM then increasing this is required.
- vm0.untyped_mmios = ["0x40000000:28"]; // RAM is the configuration for giving
the component the exact region of memory from [0x40000000, 0x40000000 + 2^28). If this
can't be given to the component then the capdl-loader-app would print an error and
stop loading the system. If this happens, then that means either the kernel isn't
making the right untypeds available at start up or that some other camkes component is
trying to use the same memory. If the error is because of the first case, then we usually
turn to creating a reserved region description in the device tree file for that platform
so that the kernel doesn't use the memory and it is therefore ensured to be in the
initial set of untypeds passed to memory.
If there is less memory available in the system than what the camkes components are
requesting, then the above configuration options need to be reduced if memory can't
be unlocked from elsewhere somehow. On a system with at least 1GiB of memory available
then it is more common that these options are too low or way too high.
I'm not quite sure what you mean about the 1GB highmem issue sorry. Are you able to