From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike D. Day" Subject: Re: [RFC] New shadow paging code Date: Mon, 17 Jul 2006 10:32:08 -0400 Message-ID: <44BB9F68.8070803@us.ibm.com> References: <20060714153907.GJ3328@york.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060714153907.GJ3328@york.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Tim Deegan wrote: > Our code must deal differently with all the different combinations of > shadow modes. However, we expect that once a guest reaches its target > paging mode, it will stay in that mode for a long time; and the host will > never change its paging mode. Rather than having a whole string of ifs in > the code based on the current guest and host paging modes, we compile > different code to deal with each pair of modes (2-on-2, 2-on-3, 2-on-4, > 3-on-3, 3-on-4, 4-on-4). (Direct mode is implemented as a special case of > m-on-m, where m is the host's current paging level.) While increasing the > size of the hypervisor overall, this should greatly decrease both the cache > footprint of the shadow code and reduce pipeline flushes from mispredicted > branches. Can you explain how this works? It is not obvious to me from the patch. In shadow2.c there is in fact a whole string of #ifs. What mechanism causes the file to be multiply compiled? Or do I misunderstand how this works? Also, can you comment on the differences and similarities with the shadow code contributed by Ben Thomas? thanks, Mike Day