From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: one question to p2m table entry type Date: Tue, 18 May 2010 11:32:17 -0700 Message-ID: <4BF2DD31.601@goop.org> References: <789F9655DD1B8F43B48D77C5D30659731E417BBD@shsmsx501.ccr.corp.intel.com> <20100518110455.GE4164@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100518110455.GE4164@whitby.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: "Jiang, Yunhong" , "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 05/18/2010 04:04 AM, Tim Deegan wrote: > At 09:17 +0100 on 05 May (1273051073), Jiang, Yunhong wrote: > >> Tim/Keir, I noticed that when translatiing p2m table type and p2m pte entry flags, there are difference handling for x86_64 and x32 like: >> >> in p2m_type_to_flags: >> #ifdef __x86_64__ >> flags = (unsigned long)(t & 0x3fff) << 9; >> #else >> flags = (t & 0x7UL) << 9; >> #endif >> >> in p2m_flags_to_type: >> /* Type is stored in the "available" bits */ >> #ifdef __x86_64__ >> return (flags >> 9) & 0x3fff; >> #else >> return (flags >> 9) & 0x7; >> >> But since we don't support pure 32 bit xen hypervisor any more, and >> for 32 PAE, we are sure have enough bit to keep these flags, why do we >> need these special handling? Are there any special reason for it? >> > The Intel SDMs (section 3.8.5, figure 3-20 in the copy in front of me) > only define three available bits in PAE PTEs; all bits above MAXPHYADDR > are reserved. If we can rely on the manuals being wrong about that, we > can extend the number of p2m types on 32-bit XEN. :) > No, the CPU will fault with a bad pte if you set the upper bits in a PAE pte. J