From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mihai =?UTF-8?Q?Don=C8=9Bu?= Subject: Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for VM introspection Date: Wed, 26 Jul 2017 20:04:46 +0300 Message-ID: <1501088686.9728.11.camel@bitdefender.com> References: <20170707143416.11195-1-alazar@bitdefender.com> <20170707143416.11195-2-alazar@bitdefender.com> <7104167e-0747-92fe-05df-1b7e1848d65f@redhat.com> <1499700768.37E8E87C5.13190@host> <1499791729.BdcecF.28697@host> <1499925466.2110.342.camel@bitdefender.com> <181883b2-75fe-d1b9-557d-c92d27f82b81@redhat.com> <1500378662.5720.38.camel@bitdefender.com> <59cf98d3-9f7c-bfc9-5a2c-7e72957478f1@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Radim =?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?= , Jan Kiszka , Stefan Hajnoczi , Adalbert Lazar , kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:55416 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdGZRFL (ORCPT ); Wed, 26 Jul 2017 13:05:11 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 9040B7FC04 for ; Wed, 26 Jul 2017 20:05:09 +0300 (EEST) In-Reply-To: <59cf98d3-9f7c-bfc9-5a2c-7e72957478f1@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, 2017-07-23 at 15:02 +0200, Paolo Bonzini wrote: > 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). OK. > > 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. I see. Then maybe we should provide a way for commands to specify an event ID. If zero, then the command is satisfied using data straight from the vCPU (when making changes), otherwise a structure associated with the event will be used as cache for all get-s/set-s and apply them all in one go when the event reply arrives. This should work nicely since we read a good deal of the register set anyway when sending the event. > > > > 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. -- Mihai Donțu