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 <hpa@linux.intel.com>

diff --git a/core/bcopy32.inc b/core/bcopy32.inc
index f058a6f..c4edc71 100644 (file)
--- a/core/bcopy32.inc
+++ b/core/bcopy32.inc
@@ -127,7 +127,7 @@ simple_pm_call:
 
                bits 32
 .in_pm:
-               mov eax,PM_DS32
+               mov ax,PM_DS32
                mov ss,eax
                lea esp,[ebp-8*4-2*4]   ; Flat mode stack
                mov es,eax
@@ -137,7 +137,7 @@ simple_pm_call:
                ; machine running on Intel VT hardware -- it can't
                ; deal with a partial transition, for no good reason.
 
-               mov al,PM_DS16_RM       ; Real-mode-like segment
+               mov al,PM_DS16          ; Real-mode-like segment
                mov fs,eax
                mov gs,eax
                mov al,PM_TSS           ; Intel VT really doesn't want
@@ -151,7 +151,7 @@ simple_pm_call:
                jmp PM_CS16:.exit
                bits 16
 .exit:
-               mov eax,PM_DS16_RM      ; "Real-mode-like" data segment
+               mov ax,PM_DS16          ; "Real-mode-like" data segment
                mov es,eax
                mov ds,eax
                mov ss,eax

diff --git a/core/bcopyxx.inc b/core/bcopyxx.inc
index 60f8172..c42af49 100644 (file)
--- a/core/bcopyxx.inc
+++ b/core/bcopyxx.inc
@@ -241,12 +241,15 @@ pm_shuffle_real_mode:
                call .here
 .here:         pop ebx
                mov eax,edi
-               add ebx,bcopy_gdt.CS16-.here
-               mov [ebx+2],ax
+               add ebx,bcopy_gdt-.here
+               mov [ebx+PM_CS16+2],ax
+               mov [ebx+PM_DS16+2],ax
                shr eax,16
-               mov [ebx+4],al
-               mov [ebx+7],ah
-               mov eax,PM_DS16_RM
+               mov [ebx+PM_CS16+4],al
+               mov [ebx+PM_CS16+7],ah
+               mov [ebx+PM_DS16+4],al
+               mov [ebx+PM_DS16+7],ah
+               mov ax,PM_DS16
                mov ds,eax
                mov es,eax
                mov fs,eax
@@ -278,7 +281,7 @@ bcopy_gdt:
        desc CS16
                dd 0000ffffh            ; 10h Code segment, use16, readable,
                dd 00009b00h            ; present, dpl 0, cover 64K
-       desc DS16_RM
+       desc DS16
                dd 0000ffffh            ; 18h Data segment, use16, read/write,
                dd 00009300h            ; present, dpl 0, cover 64K
        desc CS32

diff --git a/core/com32.inc b/core/com32.inc
index 3a762a6..7232792 100644 (file)
--- a/core/com32.inc
+++ b/core/com32.inc
@@ -196,7 +196,7 @@ com32_enter_rm:
 
                bits 16
 .in_pm16:
-               mov ax,PM_DS16_RM       ; Real-mode-like segment
+               mov ax,PM_DS16          ; Real-mode-like segment
                mov es,ax
                mov ds,ax
                mov ss,ax

diff --git a/doc/comboot.txt b/doc/comboot.txt
index cf18b2b..f5fefda 100644 (file)
--- a/doc/comboot.txt
+++ b/doc/comboot.txt
@@ -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.