Avi Kivity wrote:
Anthony Liguori wrote:
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
--- a/bincode.asm       2007-07-24 05:49:46.000000000 -0500
+++ b/bincode.asm       2007-09-29 22:14:35.000000000 -0500
@@ -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]
@@ -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.

You're right.  Good catch!

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.

Regards,

Anthony Liguori

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




diff -ur a/bincode.asm b/bincode.asm
--- a/bincode.asm	2007-07-24 05:49:46.000000000 -0500
+++ b/bincode.asm	2007-09-30 01:56:48.000000000 -0500
@@ -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]
@@ -15546,7 +15552,7 @@
 		mov ax,pm_seg.prog_d16
 		mov ds,ax
 
-		mov eax,ss
+		mov ax,bx
 		and esp,0ffffh
 		shl eax,4
 		add esp,eax
@@ -15557,6 +15563,7 @@
 		mov fs,ax
 		mov gs,ax
 
+		pop ebx
 		pop eax
 		popfw
 		o16 ret
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to