| |
| 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. |