Jeremy Fitzhardinge <jeremy at goop.org> writes: > There are a few significant differences between a Xen boot up and a native one: > > Xen has already set up a clean flat 32-bit environment with paging > enabled, so there's very little setup needed before getting into > start_kernel (basically it just needs to set %esp and make sure the > D flag is clear). We definitely don't want to be going into the > 16-bit entrypoint. Right. But that doesn't exclude the 32bit entry point. > The kernel is running in ring != 0, so ring0 instructions will > fault, and popf misbehave. Xen can (and does) emulate some of the > ring0 instructions, but not necessarily enough to deal with > startup_32 (I haven't looked at this in detail yet). Either way, > startup_32 would need to be modified to avoid the difficult cases. Sure, that is expected. > Xen also supports privileged kernels which run in ring 0, but > they're stlil fully paravirtualized kernels; they should not use > their ring0 status to set up the processor state without doing it > through Xen. > > At present, Xen also passes a pointer to an info-block in %esi. We > could hang that off a normal boot params block if that looked like a > useful thing to do. Yes. I think that would be useful. Xen passes parameter block? Is there no shim layer between Xen and the kernel it is loading? No bootloader? If there isn't some kind of bootloader thing int the middle I think we have a huge interface stability problem. > Also, the set of supported CPUs is smaller, so most of the cpuid > stuff is reundant. It would also need to be redone using the Xen > version of cpuid to get a correct set of information. > > This all makes me think it would be more awkward than helpful to have the Xen > boot path go through the normal startup_32 path. > > Zach proposed a change to the beginning of startup_32 to see if its running in > ring != 0 or if paging is already enabled, and then jumping to a > startup_paravirt entrypoint. That's workable, but it essentially means we're > creating a distinct hypervisor boot protocol. That's not necessarily a bad > thing - and it could be made to look more like the normal boot protocol - but > because the setup code is so simple there doesn't seem to be a lot to be gained > from it. In the Xen case, it makes more sense to simply have a separate > Xen-specific entrypoint to do a little bit of setup before jumping into > start_kernel. There is a lot to be gained by having a single entry point and the kernel looking at parameters it is passed and the state of the system and seeing what to do. In particular it gives us a stable ABI so the kernel and it's bootloaders can evolve independently. Exporting an entry point address is a non-trivial thing to do and to maintain. Exporting multiple entry point addresses is very difficult and expensive. Because you have to cope with the weirdness of recompiling code and relative offsets between routines changing. Eric
