Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
Steffen Winterfeldt wrote: Hi, sorry for the delay, but I've been on vacation. :-) No worries :-) 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). I wasn't able to find anything definitive in my manuals but I didn't look very hard. I figured that erring on the safe side is better anyway. Anyway, ss is already saved, so no need for an extra register. Here is my version (tested and works on my machine): This patch works for me under KVM. Thanks! Regards, Anthony Liguori --- bincode.asm (revision 650) +++ bincode.asm (working copy) @@ -15546,7 +15546,11 @@ mov ax,pm_seg.prog_d16 mov ds,ax - mov eax,ss + ; needed for KVM: + ; ss:rpl must equal cs:rpl in PM for VT. We can't rely on ss + ; maintaining its value after the transition. + + movzx eax,word [rm_seg.ss] and esp,0h shl eax,4 add esp,eax - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
Hi, sorry for the delay, but I've been on vacation. :-) On Sun, 30 Sep 2007, Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: 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. Uh, that's weird! Thanks for pointing this out. [patch] 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! Actually that is not true. 'mov eax,ss' does implicitly clear the upper 16 bits (both processor docs and hardware agree here). 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. Anyway, ss is already saved, so no need for an extra register. Here is my version (tested and works on my machine): --- bincode.asm (revision 650) +++ bincode.asm (working copy) @@ -15546,7 +15546,11 @@ mov ax,pm_seg.prog_d16 mov ds,ax - mov eax,ss + ; needed for KVM: + ; ss:rpl must equal cs:rpl in PM for VT. We can't rely on ss + ; maintaining its value after the transition. + + movzx eax,word [rm_seg.ss] and esp,0h shl eax,4 add esp,eax - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
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.0 -0500 +++ b/bincode.asm 2007-09-29 22:14:35.0 -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,0h 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. add esp,eax @@ -15557,6 +15563,7 @@ mov fs,ax mov gs,ax + pop ebx pop eax popfw o16 ret -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [GFXBOOT] [PATCH] When switching to real-mode, pass SS in a GP register
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.0 -0500 +++ b/bincode.asm 2007-09-29 22:14:35.0 -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,0h 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.0 -0500 +++ b/bincode.asm 2007-09-30 01:56:48.0 -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,0h 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/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [GFXBOOT] [PATCH] 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. Regards, Anthony Liguori Subject: [PATCH] Fix gfxboot under VT From: Anthony Liguori [EMAIL PROTECTED] This patch lets gfxboot-3.3.38 work under KVM. The fix was suggested by Avi Kivity. Signed-off-by: Anthony Liguori [EMAIL PROTECTED] diff -ur a/bincode.asm b/bincode.asm --- a/bincode.asm 2007-07-24 05:49:46.0 -0500 +++ b/bincode.asm 2007-09-29 22:14:35.0 -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,0h 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/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
