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 17:12:12 +0300 Message-ID: <1502115132.27693.153.camel@bitdefender.com> References: <20170707143416.11195-1-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> <1502112334.27693.141.camel@bitdefender.com> <9e6a9400-6ce7-9bfc-efef-338eb5e85d99@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]:45604 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751891AbdHGOMO (ORCPT ); Mon, 7 Aug 2017 10:12:14 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 755D57FC41 for ; Mon, 7 Aug 2017 17:12:13 +0300 (EEST) In-Reply-To: <9e6a9400-6ce7-9bfc-efef-338eb5e85d99@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2017-08-07 at 15:49 +0200, Paolo Bonzini wrote: > On 07/08/2017 15:25, Mihai Donțu wrote: > > > "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. > > Do you mean it needs to stop DMA as well? No, DMA can proceed normally. I remain of the opinion that KVMI users must know what guest memory ranges are OK to access by looking at MTRR- s, PAT or guest kernel structures, or a combination of all three. > > 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? > > You would have to send back something on completion, and then I am > worried of races and deadlocks.  Plus, pausing a VM at the QEMU level is > a really expensive operation, so I don't think it's a good idea to let > the introspector do this.  You can pause all VCPUs, or use memory page > permissions. Pausing all vCPU-s was my first thought, I was just trying to follow your statement: "I lean towards omitting it". :-) It will take a bit of user-space-fu, in that after issuing N vCPU pause commands in a row we will have to wait for N events, which might race with other events (MSR, CRx etc.) which need handling otherwise the pause ones will not arrive ... I wonder if there's a way to do this cleanly in kernel (piggyback on the code for pausing a single vCPU and then somehow 'coalesce' all pause events into a single KVMI_EVENT_VCPUS_PAUSED). > > > 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. > > Yes, exactly. OK. We will update the design document. -- Mihai Donțu