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
>>   
>>     
>
>
>
>