| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home