On Sun, Aug 19, 2012 at 12:32:36PM +0300, Avi Kivity wrote: > 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(). Right. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html