From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gianluca Guida Subject: Re: Two shadow page tables for HVM Date: Tue, 23 Dec 2008 13:03:02 +0100 Message-ID: <4950D376.5000802@eu.citrix.com> References: <494985DF.9040701@ncsu.edu> <20081218113225.GN460@york.uk.xensource.com> <494FDC38.7040400@ncsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <494FDC38.7040400@ncsu.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Emre Can Sezer Cc: Xen Devel List-Id: xen-devel@lists.xenproject.org Emre Can Sezer wrote: > Wouldn't this mean that the two page tables are NOT synchronized? When > we switch paging modes, wouldn't we have to rebuild the entire shadow > page tables from guest? No. When updating shadows from guest, the shadow code will update the changes for each existing shadow of the page. > When considering the performance penalties of flushing the kernel page > tables from the TLB, how significant is traversing all the shadow page > tables for the guest kernel and updating their permissions? If there > isn't an order of magnitude of difference, it might be reasonable to > take the short cut in implementation. It's up to the permission you're updating and how widely you want these permissions applied. If (e.g. NX bit) one bit in the upper level set permission for the whole part of the tree it maps, then you can just change permissions on the top level shadows. Be sure, though, to cope with the fault you get correctly. Gianluca