On 18/07/2017 13:51, Mihai Donțu wrote: > On Thu, 2017-07-13 at 09:32 +0200, Paolo Bonzini wrote: >> On 13/07/2017 07:57, Mihai Donțu wrote: >>>> Actually it makes more sense for SKIP, I think, where the introspector >>>> is actually doing emulation? >>> >>> I'm afraid I don't undestand your question, however we were looking at >>> using KVM's x86 emulator rather than putting together our own, as such >>> software might be fun to write but they take a very long time to get >>> right. I'd argue that KVM's emulator has already seen a lot of >>> coverage. >> >> Of course! But there could be some special cases (e.g. hypercalls) >> where you do emulation on your own. In that case, KVMI_SET_REGS + SKIP >> is the right thing to do. > > I think I finally understand what you're saying. That SKIP would tell > the introspection subsystem to just write back the registers and enter > the guest, no in-host emulation needed. So, to reiterate, the possible > actions would be: > > * SKIP - re-enter the guest (the introspection tool has adjusted all > registers) > * RETRY - re-enter the guest > * ALLOW - use the emulator > * CRASH - kill the guest process > > It seems that SKIP requires a variant of KVMI_SET_REGS (_FULL?) that > sets all registers that might have been affected by the emulation > (control, MSR-s, MMX/SSE/AVX). I guess there can be an usecase for > that. It also looks like its identical with KVMI_SET_REGS_FULL + RETRY. One difference that comes to mind between SKIP and RETRY is that SKIP would inject a singlestep exception if TF was 1 on entry, and clear the interrupt shadow. RETRY would not do either of those. (The name for SKIP comes from the KVM function kvm_skip_emulated_instruction). > We were hoping we can > reduce the overhead by a bit by bundling KVMI_SET_REGISTERS with the > event response. > > If I have not managed to convince you, I think we can go ahead and keep > them separate, have an initial implementation and see some actual > performance numbers. Should be no hassle. I think you should implement transactions in the protocol, so effectively KVMI_SET_REGISTERS would be bundled with the event response anyway. Paolo >>> In the future we are looking at maybe moving away from it on Intel-s, >>> by way of VMFUNC and #VE. >>> >>>> But why is KVMI_SET_REGS slower than a set regs command followed by an >>>> action? >>> >>> To be honest, we just looked at the Xen implementation which gates >>> writing back the registers to VMCS on them actually having been >>> changed. >> >> That would be possible on KVMI too. Just don't do the KVMI_SET_REGS >> unless the registers have changed. >
