"H. Peter Anvin" <hpa@xxxxxxxxx> writes: > Eric W. Biederman wrote: >> >> I'm tempted to just reload the segments in setup.S, but that might >> break loadlin support or one of the other bootloaders that starts the >> kernel in 32bit mode so we need to be careful. >> > > We already load all the segments in setup.S. I'm retaining this in my > rewrite. Good. I guess I had moved it there in my last cleanup but I wasn't brave enough yet to remove the reloads from both version of head.S yet. We should probably load the segment registers in trampoline.S as well that would simplify things a little bit. > Given that I'm rewriting the whole thing, if there are things you want > setup.S to do, now is the time to ask. The big wish list item would be subarch detection (at least if we need it early). As we are quickly moving to infrastructure that can runtime switch between subarch's if we can detect the difference. For the paravirt subarchitectures we are actually going to skip past setup.S So the big thing we need to start doing is to document the 32bit entry point and what can be expected of it etc, especially in the paravirt context. But that isn't a setup.S problem. Oh. Yes. We need a parameter structure in the kernel, that documents what %esi points to later. What arguments can be found in the bootloader data. If you are playing with setup.S in C that tends to be a setup.S function. Andi already has a call to verify_cpu so we abort if the cpu can't handle our current kernel. While that is not perfect aborting gracefully in setup.S is a lot better then a lot of the alternatives. Mostly what we need is to sort through the requirements of this next boot protocol revision for paravirt loaders so we can do that cleanly. It will probably need a subarch type field and a subarch data pointer field, but except for being stored in Setup.S that isn't much of a setup.S problem either. Eric _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
