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, 02 Aug 2017 16:32:29 +0300 Message-ID: <1501680749.15747.319.camel@bitdefender.com> References: <20170707143416.11195-1-alazar@bitdefender.com> <20170707143416.11195-2-alazar@bitdefender.com> <7104167e-0747-92fe-05df-1b7e1848d65f@redhat.com> <1499934995.2110.345.camel@bitdefender.com> <1d3e3fc7-5fec-037e-4be4-82a380c85972@redhat.com> <1501172635.8856.4.camel@bitdefender.com> <5f499fe6-0ac8-56e7-a4f5-ba6809cc7c6a@redhat.com> <1501175973.8856.11.camel@bitdefender.com> <1501674729.15747.282.camel@bitdefender.com> <1b3467e4-1d67-dacd-7436-6a07c08f597b@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, Tamas K Lengyel To: Paolo Bonzini Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:37952 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbdHBNcb (ORCPT ); Wed, 2 Aug 2017 09:32:31 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 955587FC2A for ; Wed, 2 Aug 2017 16:32:29 +0300 (EEST) In-Reply-To: <1b3467e4-1d67-dacd-7436-6a07c08f597b@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2017-08-02 at 14:27 +0200, Paolo Bonzini wrote: > On 02/08/2017 13:52, Mihai Donțu wrote: > > I think it might help to distinguish two situations in which we require > > the guest _or_ a single vCPU to be paused. Our initial KVMI_PAUSE_GUEST > > command can be translated into a qemu pause. In our particular usecase > > we made special arrangements to call it as few times as possible > > assuming it's very costly. The other is needed only by the internal KVM > > code for situations similar to: > > > >   kvm_pause_vcpu(vcpu); > >   vcpu_load(vcpu); > >   kvm_arch_vcpu_ioctl_get_regs(vcpu, regs); > >   vcpu_put(vcpu); > >   kvm_unpause_vcpu(vcpu); > > > > or more generally put, for accesses that involve the vCPU state > > (registers, MSR-s, exceptions etc.), no guest memory involved. > > > > Here kvm_pause_vcpu() will only pull the vCPU out of the guest and, if > > so, make it somehow available for quick re-entry with > > kvm_unpause_vcpu(). If said vCPU is already out, then the function will > > be a no-op. Obviously, kvm_{pause,unpause}_vcpu() will do nothing if > > we're currently handling an event or one is pending. > > Understood.  The issue is that there is an inherent race between > anything userspace is doing and get_regs.  What are the cases where you > need to get regs or similar outside an event? We have currently identified three cases: * initial hooking of a guest * periodically checking the integrity of data that is not properly placed into a page and thus cannot be efficiently tracked via SPT * injecting processes > > One exception that might have a better solution is: > > > >   kvm_pause_all_vcpus(kvm); > >   kvm_set_page_access(kvm, gfn); /* pause for get too? */ > >   kvm_unpause_all_vcpus(kvm); > > > > There might be a way to make the change and then IPI all vCPU-s without > > pulling them out of the guest. > > For that I think KVMI should define a VM-wide "mask" layered over the > actual memory map permissions.  Such a command can be implemented > relatively easily by hooking into the callers of __gfn_to_pfn_memslot > and kvm_vcpu_gfn_to_hva_prot. -- Mihai Donțu