Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Nailing down the interface as hard as possible is a good idea, to
avoid tying your hands for the future.
Erm, I guess I see what you mean, but it comes to the effect of tying
your hands now in a specific way, rather than having them tied in an
unknown way later on...
Sort of. The problem is you can frequently not
But I hadn't noticed the 32-bit boot protocol spec go in. Unfortunately
it isn't useful for booting a pv Xen guest; I just mailed my comments.
I hope we can iterate this to something more generally useful before
getting too wedded to the current protocol.
I'm not so sure about that. Xen PV is rather fundamentally a different
beast, hence the platform field recently added to the protocol.
2. Also, Xen reserves the last chunk of the GDT for its own
descriptors, and by default boots the guest with the segment
registers preloaded with selectors pointing to flat 4G descriptors
in this range. These segments are not a full 4G, since it uses
segment limits to protect the hypervisor from guests. The limits
are as large as they can possibly be. I like to see the boot
protocol require that all segments registers are preloaded with
large flat 32-bit descriptors, but not require a specific selector
value. I'd happy to require the GDT to be active, so the segment
registers can be reloaded with their current values, until the
kernel establishes its own GDT.
This is addressed by the "don't reload segments" bit in LOADFLAGS.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
