|author||H. Peter Anvin <email@example.com>||2009-04-16 17:19:24 -0700|
|committer||H. Peter Anvin <firstname.lastname@example.org>||2009-04-16 17:19:24 -0700|
bcopyxx: when going to 16-bit PM, might as well do it right
When entering 16-bit PM after shuffle and boot, we might as well do so sanely. Specifically, set up the data segments so that they match the code segment, generating a 16-bit "tiny" model environment. This makes it a lot saner to bootstrap a proper PM environment from there if that is what the user intends. For the presumably more common case of RM entry, it won't do any harm, and it's only a handful of additional instructions. Signed-off-by: H. Peter Anvin <email@example.com>
Diffstat (limited to 'doc')
1 files changed, 3 insertions, 2 deletions
diff --git a/doc/comboot.txt b/doc/comboot.txt
index cf18b2b6..f5fefdaf 100644
@@ -952,5 +952,6 @@ AX=0024h [3.80] Cleanup, shuffle and boot, raw version
and possibly other virtualization solutions.
In both mode 0 and mode 1, the data segments will be loaded
- with base-zero read/write segments. For mode 0, B=0 and the
- limits will be 64K, for mode 1, B=1 and the limits will be 4 GB.
+ with read/write data segments, matching the respective code
+ segment. For mode 0, B=0 and the limits will be 64K, for mode
+ 1, B=1 and the limits will be 4 GB.