[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.