From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for
 VM introspection
Date: Mon, 7 Aug 2017 14:18:35 +0200
Message-ID: <7e06849b-5c2d-9dc2-46b5-9a883750f488@redhat.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>
 <f9eeaea1-1fc2-0298-a4f8-77eed8c587d3@redhat.com>
 <CABfawh=nSA13MoSYtrnY21tp07kvsMe1wo8TYwEs5nFVUNJssQ@mail.gmail.com>
 <f3d063ad-5be4-f438-b31e-c3a34fe13da3@redhat.com>
 <1501674729.15747.282.camel@bitdefender.com>
 <1b3467e4-1d67-dacd-7436-6a07c08f597b@redhat.com>
 <1501680749.15747.319.camel@bitdefender.com>
 <c7eb8d64-9083-2d86-3e99-a6fd729fb7bb@redhat.com>
 <1501683449.15747.334.camel@bitdefender.com>
 <3e9ee026-260f-6a47-8482-d9daaac98d5a@redhat.com>
 <1501860597.27693.28.camel@bitdefender.com>
 <aac0f2642842499db89ac588137773c1@mb2xmail.bitdefender.biz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Jan Kiszka <jan.kiszka@siemens.com>,
        Stefan Hajnoczi <stefanha@redhat.com>,
        Adalbert Lazar <alazar@bitdefender.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Tamas K Lengyel <tamas.k.lengyel@gmail.com>
To: Andrei Vlad LUTAS <vlutas@bitdefender.com>,
        =?UTF-8?Q?Mihai_Don=c8=9bu?= <mdontu@bitdefender.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:35466 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753112AbdHGMSs (ORCPT <rfc822;kvm@vger.kernel.org>);
        Mon, 7 Aug 2017 08:18:48 -0400
In-Reply-To: <aac0f2642842499db89ac588137773c1@mb2xmail.bitdefender.biz>
Content-Language: en-US
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.

"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.

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.

Paolo