When switching to real-mode, pass SS in a GP register

Hi Steffen,

As Avi pointed out, VT requires that SS.RPL == CS.RPL. We're seeing gfxboot fail under KVM because ss = 0x5761 while cs = 0x4004 during the transition from real mode to protected mode. The attached patch passes the value of ss through ebx since KVM has to sanitize the value of ss to make VT happy.

I've tested this with a remastered Ubuntu Gutsy install CD. I couldn't find the right gfxboot theme for the openSuSE install CD I have so I wasn't able to test it.

I suspect that Xen should have a very similar problem as I can't think of a possible way to work around this.

diff -ur a/bincode.asm b/bincode.asm

bincode.asm +6 -0

@@ -15519,6 +15519,7 @@
 switch_to_pm:
 		pushf
 		push eax
+		push ebx
 
 		mov eax,cr0
 

@@ -15534,6 +15535,11 @@
 		mov word [cs:rm_seg.fs],fs
 		mov word [cs:rm_seg.gs],gs
 
+		;; ss:rpl must equal cs:rpl in PM for VT.  we can't rely on ss
+		;; maintaining it's value after the transition so we have to
+		;; pass it in a GP register
+		mov ebx,ss
+	
 		or al,1
 		o32 lgdt [cs:pm_gdt]
 		o32 lidt [cs:pm_idt]

bincode.asm +1 -0

 		add esp,eax

@@ -15557,6 +15563,7 @@
 		mov fs,ax
 		mov gs,ax
 
+		pop ebx
 		pop eax
 		popfw
 		o16 ret

Quoted 43 lines · Anthony Liguori

Hi Steffen,

As Avi pointed out, VT requires that SS.RPL == CS.RPL. We're seeing gfxboot fail under KVM because ss = 0x5761 while cs = 0x4004 during the transition from real mode to protected mode. The attached patch passes the value of ss through ebx since KVM has to sanitize the value of ss to make VT happy.

I've tested this with a remastered Ubuntu Gutsy install CD. I couldn't find the right gfxboot theme for the openSuSE install CD I have so I wasn't able to test it.

I suspect that Xen should have a very similar problem as I can't think of a possible way to work around this.

diff -ur a/bincode.asm b/bincode.asm

bincode.asm +6 -0

@@ -15519,6 +15519,7 @@
 switch_to_pm:
 		pushf
 		push eax
+		push ebx
 
 		mov eax,cr0
 

@@ -15534,6 +15535,11 @@
 		mov word [cs:rm_seg.fs],fs
 		mov word [cs:rm_seg.gs],gs
 
+		;; ss:rpl must equal cs:rpl in PM for VT.  we can't rely on ss
+		;; maintaining it's value after the transition so we have to
+		;; pass it in a GP register
+		mov ebx,ss
+	
 		or al,1
 		o32 lgdt [cs:pm_gdt]
 		o32 lidt [cs:pm_idt]

bincode.asm line 15558

Quoted 8 lines

bincode.asm +1 -1

@@ -15546,7 +15552,7 @@
 		mov ax,pm_seg.prog_d16
 		mov ds,ax
 
-		mov eax,ss
+		mov eax,ebx
 		and esp,0ffffh
 		shl eax,4
 

This is subtly wrong, I think. First, note that 'mov eax,ss' only affects ax, not the high 16 bits. The note that the original code happily shifts eax which is half ss, half garbage left by 4 bits and uses that to generate a 32-bit result.

The reason it worked before was that bits 16-29 of eax are already clear by virtue of having come from cr0. But now you're using ebx which hasn't had that magic clearing.

In your comment to the kvm bug you say that the patch allows you to boot, so perhaps bits 16-29 of ebx are already clear here, or my analysis is mistaken.

Quoted 5 lines

bincode.asm +0 -0

 		add esp,eax

@@ -15557,6 +15563,7 @@
 		mov fs,ax
 		mov gs,ax
 

bincode.asm line 15569

Quoted 6 lines

bincode.asm +1 -0

+		pop ebx
 		pop eax
 		popfw
 		o16 ret

Quoted 7 lines · Avi Kivity

Quoted 5 lines · Anthony Liguori

As Avi pointed out, VT requires that SS.RPL == CS.RPL. We're seeing gfxboot fail under KVM because ss = 0x5761 while cs = 0x4004 during the transition from real mode to protected mode. The attached patch passes the value of ss through ebx since KVM has to sanitize the value of ss to make VT happy.

Quoted 9 lines

This is subtly wrong, I think. First, note that 'mov eax,ss' only affects ax, not the high 16 bits. The note that the original code happily shifts eax which is half ss, half garbage left by 4 bits and uses that to generate a 32-bit result.

The reason it worked before was that bits 16-29 of eax are already clear by virtue of having come from cr0. But now you're using ebx which hasn't had that magic clearing.

You're right. Good catch!

Quoted 4 lines

In your comment to the kvm bug you say that the patch allows you to boot, so perhaps bits 16-29 of ebx are already clear here, or my analysis is mistaken.

Yeah, I just got lucky with ebx I guess :-) Attached is an updated patch that fixes this problem.

Hi,

sorry for the delay, but I've been on vacation. :-)

Quoted 2 lines

You're right. Good catch!

Actually that is not true. 'mov eax,ss' does implicitly clear the upper 16 bits (both processor docs and hardware agree here).

Anyway, ss is already saved, so no need for an extra register. Here is my version (tested and works on my machine):

bincode.asm +0 -0

@@ -15546,7 +15546,11 @@
 		mov ax,pm_seg.prog_d16
 		mov ds,ax