Re: VMX and save/restore guest in virtual-8086 mode

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
> On 04/08/2010 10:22 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>    
>>> On 04/07/2010 11:24 PM, Marcelo Tosatti wrote:
>>>      
>>>> During initialization, WinXP.32 switches to virtual-8086 mode, with
>>>> paging enabled, to use VGABIOS functions.
>>>>
>>>> Since enter_pmode unconditionally clears IOPL and VM bits in RFLAGS
>>>>
>>>>           flags = vmcs_readl(GUEST_RFLAGS);
>>>>           flags&= ~(X86_EFLAGS_IOPL | X86_EFLAGS_VM);
>>>>           flags |= (vmx->rmode.save_iopl<<   IOPL_SHIFT);
>>>>           vmcs_writel(GUEST_RFLAGS, flags);
>>>>
>>>>
>>>>        
>>> Looks like KVM_SET_REGS should write rmode.save_iopl (and a new save_vm)?
>>>      
>> Just like we manipulate the flags for guest debugging in the
>> set/get_rflags vendor handlers, the same should happen for IOPL and VM.
>> This is no business of enter_pmode/rmode.
>>    
> 
> This is vendor specific code, and it isn't manipulating guest values, 
> only host values (->set_rflags() is called when the guest value changes, 
> which isn't happening here).  Of course some refactoring will be helpful 
> here.

Actually, the bug is that enter_pmode/rmode update save_iopl (and that
no one saves the VM bit). That should happen in vmx_set_rflags to also
keep track of changes _while_ we are in rmode. enter_rmode/pmode should
just trigger a set_rflags to update things. And vmx_get_rflags must
properly inject the saved flags instead of masking them out.

> 
>>>> The following patch fixes it, but it has some drawbacks:
>>>>
>>>> - cpu_synchronize_state+writeback is noticeably slow with tpr patching,
>>>>     this makes it slower.
>>>>
>>>>        
>>> Isn't it a very rare event?
>>>      
>> It has to be - otherwise the decision to go for full sync and individual
>> get/set IOCTL would have been wrong. What happens during tpr patching?
>>
>>    
> 
> tpr patching listens for instructions which access the tpr and patches 
> them to a call instruction (targeting some hacky code in the bios).  
> Since there are a limited number of such instructions (20-30 IIRC) you 
> expect tpr patching to happen very rarely.

Then I wonder why it is noticeable.

> 
>>>> - Its a fugly workaround.
>>>>
>>>>        
>>> True.
>>>
>>>      
>> Still likely the way to go for old kernels.
>>
>>    
> 
> It's a bugfix that can go into -stable and supported distribution kernels.

Well, would be happy to throw out tones of workaround based on this
approach. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux