[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: one question to p2m table entry type
Oops, sorry, I should notice the (must be 0) :$ --jyh >-----Original Message----- >From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx] >Sent: Wednesday, May 19, 2010 2:32 AM >To: Tim Deegan >Cc: Jiang, Yunhong; xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser >Subject: Re: [Xen-devel] Re: one question to p2m table entry type > >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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |