From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Write bit in Shadow Page Table Entry Date: Sun, 26 Jul 2009 14:43:46 +0300 Message-ID: <4A6C4172.5010901@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm To: Lynda Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36859 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752940AbZGZLjY (ORCPT ); Sun, 26 Jul 2009 07:39:24 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 07/23/2009 11:49 PM, Lynda Yang wrote: > Hi, > As I understand, the KVM code (kvm-86) may clear the write bit when > setting a shadow page table entry so that it can detect when an entry > needs to be marked dirty later. However, it also plays with the write > bit depending on whether the shadow page is allowed to be unsynched or > not. I'm not quite clear on the latter, so if anyone can provide some > insights it would be very much appreciated. Or perhaps even more > helpful...if it is possible to provide a clear picture of how KVM > generally plays with an entry's write bit. > Let's see. 1. If the spte was derived from a guest pte, then the writeable bit reflects the guest permissions. If not (nested paging, real mode), the writeable bit is 1. 2. When we log dirty pages, writeable bits for the memory we are interested in are cleared. 3. If the spte points at a shadow page, the writeable bit is cleared to 0 so that we are informed of updates to page tables. 4. Under certain conditions[1], we allow a shadowed guest page table to be writeable. This happens on a write fault to a guest page table. [1] The conditions are: the page is the lowest-level mapping, and there are no other uses of the page as a paging element. -- error compiling committee.c: too many arguments to function