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: Tue, 18 Jul 2017 14:51:02 +0300 Message-ID: <1500378662.5720.38.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> 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]:46838 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751469AbdGRLvE (ORCPT ); Tue, 18 Jul 2017 07:51:04 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id A51C77FC42 for ; Tue, 18 Jul 2017 14:51:02 +0300 (EEST) In-Reply-To: <181883b2-75fe-d1b9-557d-c92d27f82b81@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > > 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