Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Mock up table init work for Linux
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Type||Name||Latest commit message||Commit time|
|Failed to load latest commit information.|
Compile ======= Run: make Simulated boots ============== This programs simulates boot in on both bare metal and xen. The goal of the code is to illustrate an issue of dead code and how we can fix this. Emulate bare metal boot: ./main Emulate xen boot: ./main -x x86 bzimage parser ================ An x86 image parser has been added to aid the integration requirements of using futher boot_params for dead code concerns. Example usage: ./parse-bzimage ~/linux/arch/x86/boot/bzImage kernel: /home/mcgrof/linux/arch/x86/boot/bzImage kernel size: 5668000 bytes Going to parse kernel... Xen Expects: 0x53726448 Qemu Expects: 0x53726448 On image: 0x53726448 bzImage protocol Version: v2.13 Xen hdr->version: 525 Qemu protocol: 525 Qemu VERSION(2,8): 520 ------------------------------------------------- Boot protocol 2.07: 0x0207 (supports hardware_subarch) Boot protocol 2.08: 0x0208 Boot protocol 2.09: 0x0209 Boot protocol 2.10: 0x020a Boot protocol 2.11: 0x020b Boot protocol 2.12: 0x020c Boot protocol 2.13: 0x020d Member Offset Expected Match ------------------------------------------------------------------------- setup_header->loadflags 0x0211 0x0211 YES setup_header->hardware_subarch 0x023c setup_header->hardware_subarch_data 0x0240 TODO ==== This should be all done now! Table solution history ====================== The init table solution implemented here is a combination of how the Linux IOMMU init framework was implemented *and* how GPXE sorts its own init work. Table sorting ============= The Linux IOMMU solution gives us dependency annotations, so one set of routines will not run until its dependency runs. The sorting for this takes place with a C routine which ultimately memmove()'s the routines in order. The sorting done by the GPXE solution is all done by the linker by the good 'ol SORT() through in the object's linker script. We want to enable different subsystems to implement their own table solutions and this can mean having different init structure members, that is how the gpxe solution works. Sorting is done automatically for you through linker at build time. The sorting through the IOMMU init solution works using the actual specific structure for the subsystem used and the semantics for the sorting must be clearly documented and defined. For instance the original IOMMU init solution requires only one init solution to have a NULL set for its depends callback. For our mockup x86 init solution we are allowing both "depends" and "detect" to be NULL. For changes to how our sorting implementation was modified refer to commit 9e01858bbc74a11 ("init: enable support for no depends() callback). The sorting for routines that do not have a "depends" callback set would happen through the order table level used, a la gpxe solution. When the order levels are the same we rely on order of linking -- for instance: placement of the routines in the C file, and at the file level based on order in the Makefile. Furthermore, upon initialization the mockup x86 init solution relies on the subarchitecture to skip routines which are not supported or intended for its subarchitecture. It might be possible to share a common C sort routine for all tables but the first challenge is we'd likely be constraining our init structures. For instance since the current sorting looks for an init routine's "depends" callback, that callback will be placed in a specific location as part of the structure. In order to share a sort we'd have to enforce a common set of table structures for at least the sorting semantics, for instance this could perhaps be accomplished by placing all relevant members relevant to sorting semantics in the beginning of the structure. The next challenge has to do with size, given that we move structures around with memmove() and this is done depending on the size of the init structure, and that is up to each subsystem to define. This could be resolved by fixating the size of all table init structures. For now each subsystem must then define its own sorting scheme. A sorting algorithm is only necessary if the linker script sorting does not suffice for the semantics of the subsystem. File mapping upstream ===================== In case this project maintains a matching with upstream this project strives to maintain a one to one direct mapping as things are or we hope would be on upstream Linux.