On 08/17/2012 08:29 PM, Marcelo Tosatti wrote:
> On Thu, Aug 16, 2012 at 05:54:49PM +0300, Avi Kivity wrote:
>> Instead of populating the the entire register file, read in registers
>> as they are accessed, and write back only the modified ones.  This
>> saves a VMREAD and VMWRITE on Intel (for rsp, since it is not usually
>> used during emulation), and a two 128-byte copies for the registers.
>> 
> 
>> @@ -2715,14 +2764,17 @@ int emulator_task_switch(struct x86_emulate_ctxt 
>> *ctxt,
>>  {
>>      int rc;
>>  
>> +    invalidate_registers(ctxt);
>>      ctxt->_eip = ctxt->eip;
>>      ctxt->dst.type = OP_NONE;
>>  
>>      rc = emulator_do_task_switch(ctxt, tss_selector, idt_index, reason,
>>                                   has_error_code, error_code);
>>  
>> -    if (rc == X86EMUL_CONTINUE)
>> +    if (rc == X86EMUL_CONTINUE) {
>>              ctxt->eip = ctxt->_eip;
>> +            writeback_registers(ctxt);
>> +    }
>>  
>>      return (rc == X86EMUL_UNHANDLEABLE) ? EMULATION_FAILED : EMULATION_OK;
>>  }
> 
> 
> No clear point when emulator register cache is active, when it is
> not (AFAICS this patch does not invalidate registers on emulation start
> (the above being one of the exceptions) does not clear valid bit on
> writeback-to-vcpu-cache on emulation exit).

It is cleared when emulation starts.  For the non-insn-emulation entry
points, there is an explicit invalidate.  For the emulation entry point,
there is a memset() that clears everything up to _regs, which includes
the cache.  This discrepancy isn't nice, but it preexists.  I don't know
whether we should decompose the memset() or not, it is rather efficient.

> 
> Concern is that emulator can start with cached registers marked as valid 
> but in fact are invalid from previous emulation round.
> 
> Maybe move invalidate() to init_emulate_ctxt?
> 

See the memset() in init_decode_cache().

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to