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
