From: "Mihai Donțu" <mdontu@bitdefender.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <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>,
"Andrei Vlad LUTAS" <vlutas@bitdefender.com>
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 [thread overview]
Message-ID: <1502112334.27693.141.camel@bitdefender.com> (raw)
In-Reply-To: <7e06849b-5c2d-9dc2-46b5-9a883750f488@redhat.com>
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
next prev parent reply other threads:[~2017-08-07 13:25 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 14:34 [RFC PATCH v2 0/1] VM introspection Adalbert Lazar
2017-07-07 14:34 ` [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for " Adalbert Lazar
2017-07-07 16:52 ` Paolo Bonzini
2017-07-10 15:32 ` alazar
2017-07-10 17:03 ` Paolo Bonzini
2017-07-11 16:48 ` Adalbert Lazar
2017-07-11 16:51 ` Paolo Bonzini
2017-07-13 5:57 ` Mihai Donțu
2017-07-13 7:32 ` Paolo Bonzini
2017-07-18 11:51 ` Mihai Donțu
2017-07-18 12:02 ` Mihai Donțu
2017-07-23 13:02 ` Paolo Bonzini
2017-07-26 17:04 ` Mihai Donțu
2017-07-26 17:25 ` Tamas K Lengyel
2017-07-27 14:41 ` Mihai Donțu
2017-07-27 13:33 ` Paolo Bonzini
2017-07-27 14:46 ` Mihai Donțu
2017-07-13 8:36 ` Mihai Donțu
2017-07-13 9:15 ` Paolo Bonzini
2017-07-27 16:23 ` Mihai Donțu
2017-07-27 16:52 ` Paolo Bonzini
2017-07-27 17:19 ` Mihai Donțu
2017-08-01 10:40 ` Paolo Bonzini
2017-08-01 16:33 ` Tamas K Lengyel
2017-08-01 20:47 ` Paolo Bonzini
2017-08-02 11:52 ` Mihai Donțu
2017-08-02 12:27 ` Paolo Bonzini
2017-08-02 13:32 ` Mihai Donțu
2017-08-02 13:51 ` Paolo Bonzini
2017-08-02 14:17 ` Mihai Donțu
2017-08-04 8:35 ` Paolo Bonzini
2017-08-04 15:29 ` Mihai Donțu
2017-08-04 15:37 ` Paolo Bonzini
2017-08-05 8:00 ` Andrei Vlad LUTAS
2017-08-07 12:18 ` Paolo Bonzini
2017-08-07 13:25 ` Mihai Donțu [this message]
2017-08-07 13:49 ` Paolo Bonzini
2017-08-07 14:12 ` Mihai Donțu
2017-08-07 15:56 ` Paolo Bonzini
2017-08-07 16:44 ` Mihai Donțu
2017-08-02 13:53 ` Mihai Donțu
2017-07-27 17:06 ` Mihai Donțu
2017-07-27 17:18 ` Paolo Bonzini
2017-07-07 17:29 ` [RFC PATCH v2 0/1] " Paolo Bonzini
2017-08-07 15:28 ` Mihai Donțu
2017-08-07 15:44 ` Paolo Bonzini
2017-07-12 14:09 ` Konrad Rzeszutek Wilk
2017-07-13 5:37 ` Mihai Donțu
2017-07-14 16:13 ` Konrad Rzeszutek Wilk
2017-07-18 8:55 ` Mihai Donțu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1502112334.27693.141.camel@bitdefender.com \
--to=mdontu@bitdefender.com \
--cc=alazar@bitdefender.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=stefanha@redhat.com \
--cc=tamas.k.lengyel@gmail.com \
--cc=vlutas@bitdefender.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.