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: Mon, 07 Aug 2017 16:25:34 +0300 Message-ID: <1502112334.27693.141.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> <1501680749.15747.319.camel@bitdefender.com> <1501683449.15747.334.camel@bitdefender.com> <3e9ee026-260f-6a47-8482-d9daaac98d5a@redhat.com> <1501860597.27693.28.camel@bitdefender.com> <7e06849b-5c2d-9dc2-46b5-9a883750f488@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 , Andrei Vlad LUTAS To: Paolo Bonzini Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:44588 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751247AbdHGNZg (ORCPT ); Mon, 7 Aug 2017 09:25:36 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 510787FC41 for ; Mon, 7 Aug 2017 16:25:35 +0300 (EEST) In-Reply-To: <7e06849b-5c2d-9dc2-46b5-9a883750f488@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2017-08-07 at 14:18 +0200, Paolo Bonzini wrote: > On 05/08/2017 10:00, Andrei Vlad LUTAS wrote: > > Of course, just how Paolo suggested, we can place finer-grained > > intercepts (such as execute-protect a page in order to ensure no VCPU > > runs code from it while we modify it), but this is a more complicated > > solution and we've never had to think for something other than simply > > pausing the VCPUs, since that was always available so far. > > > > Hope this piece of info helps. > > We can certainly add a "pause the VCPU with a given id" command.  The > command reports its success with an event, and replying to the event > restarts the VCPU.  If the VCPU is currently in userspace, the event > would be delayed until the next time KVM is re-entered, but this should > not be an issue in general.  The introspector can operate as if the VCPU > was paused. I have a plan to modify our application a bit and see how often we query a vCPU outside an event handler. If it's seldom enough, a command that pauses the vCPU and triggers an event should be just fine. > "Pause all VCPUs and stop all DMA" would definitely be a layering > violation, so it cannot be added. > > "Pause all VCPUs" is basically a shortcut for many "pause the VCPU with > a given id" commands.  I lean towards omitting it. The case where the introspector wants to scan the guest memory needs a KVMI_PAUSE_VM, which as discussed in a previous email, can be the actual qemu 'pause' command. However, we would like to limit the communication channels we have with the host and not use qmp (or libvirt/etc. if qmp is not exposed). Instead, have a command that triggers a KVM_RUN exit to qemu which in turn will call the underlying pause function used by qmp. Would that be OK with you? > However, now that I'm thinking of it, we need a new event for "new VCPU > created".  When the event is enabled, newly-created VCPUs should be in > paused mode. I assume you are thinking about vCPU hotplug here. If so, yes, an event that gives the introspector the chance to update its internal bookkeeping would be useful. -- Mihai Donțu