Re: [RFC PATCH 08/19] kvm: Add the introspection subsystem

From: Paolo Bonzini <pbonzini@redhat.com>
To: "Mihai Donțu" <mdontu@bitdefender.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Adalbert Lazar" <alazar@bitdefender.com>,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH 08/19] kvm: Add the introspection subsystem
Date: Wed, 21 Jun 2017 14:57:48 +0200	[thread overview]
Message-ID: <e5f95fac-3bb3-c740-0f44-233bcc701e49@redhat.com> (raw)
In-Reply-To: <1498048592.24580.29.camel@bitdefender.com>

On 21/06/2017 14:36, Mihai Donțu wrote:
> The entire mechanism for altering spte-s will need a separate
> discussion, because right now it interferes with other mmu features
> like dirty page logging and possibly other that I might not be aware
> of.

Okay, this is the stuff that should be put in the cover letter.  The
current cover letter instead is an attempt at documentation that should,
of course, be in Documentation/ instead. :)

I think the right way to do it is to rebuild the MMU when the radix tree
is modified, with KVM_REQ_MMU_SYNC (or maybe even kvm_mmu_reset_context
is enough, I am not sure).  kvm_mmu_get_page can modify role.access
according to the result of the radix tree lookup.  When you make the
page read-only, the role (which is part of the hash key) changes and the
EPT tables will also be made read-only.

Paolo

> The present code merely illustrates what we're really trying to
> achieve: control the page permissions in the shadow page tables. The
> mechanics are quite simple: while a VCPU is paused the introspection
> tool creates a list of all spte's it wants to alter and then it
> unpauses the VCPU which, on its wait back into the guest, walks the
> list and applies the changes. This list-based approach is used because
> sometimes accessing spte-s requires access to qemu's address space
> which is tricky to do when the introspection tool runs as a separate
> process. We tried using something on top of switch_mm() but it proved
> unreliable. It also requires exporting some very deep x86-specific data
> in order to build kvm-intel.ko.
> 
>> How does this work when multiple VCPUs are running with different MMU
>> roles?  One VCPU is emptying the access_list for all, but
>> kvm_mmu_set_spte is using for_each_shadow_entry per-VCPU.
> Indeed, here we assume all VCPU-s' spt pointers are loaded with the
> same address. A correct approach would iterate over all vCPU-s and I
> suspect it would need to be a bit more complex with Intel's multiple
> EPT views.
> 