From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Monitoring access to a guest page? Date: Thu, 06 Nov 2008 17:56:19 +0200 Message-ID: <491313A3.40006@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list To: Brendan Dolan-Gavitt Return-path: Received: from mx2.redhat.com ([66.187.237.31]:58671 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750754AbYKFP4b (ORCPT ); Thu, 6 Nov 2008 10:56:31 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Brendan Dolan-Gavitt wrote: > Hi, > > I'm working on a patch to let me monitor reads and writes to a > particular guest page. The overall strategy is: > 1. Mark the guest page as non-present. > 2. In the PF handler, if the access is to the monitored page, log, and > emulate the instruction. > > When I asked about this in #kvm, some kind folks pointed out that this > is how MMIO is handled. So after looking through the MMIO code, the > new plan is: > 1. Create a new MMIO handler (a kvm_io_device) that will shadow a > guest page. > 2. Copy the page to be monitored from the guest and store it in the > private region of the new IO device. (using kvm_read_guest). > Basically, create a shadow copy of the page. > 3. Mark the page as non-present. > 4. Register the IO device, have its in_range check whether the address > is in the page being watched. > 5. In the IO device's read/write handler, service reads and writes > from the shadow copy, and log. > > So I have two questions: > 1. Does this all seem reasonably correct? > 2. What's the best way to accomplish step 3? I can't seem to find a > function in mmu.c that will do this, but it seems overly complicated > to use kvm_guest_write to modify the PTE by hand. It's the other way round. All pages are not-present unless made present by the mmu. All you have to do is _not_ register a memory slot that contains your page. When the guest accesses this memory, the mmu will _not_ instantiate a present pte, and will forward all accesses to your mmio handler. It's going to be slow, though. -- error compiling committee.c: too many arguments to function