one question to p2m table entry type

one question to p2m table entry type

[Jiang, Yunhong]

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?

Thanks
--jyh

Re: one question to p2m table entry type

[Keir Fraser]

I think you're right, and this was probably too subtle to pick up in the
initial phase of code cleanup when non-pae support was removed. I think
Tim's away for a week or two now so you may not get a definitive response
for a little while.

 -- Keir

On 05/05/2010 09:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> 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?
> 
> Thanks
> --jyh
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: one question to p2m table entry type

[Tim Deegan]

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. :)

Cheers,

Tim.


-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Re: one question to p2m table entry type

[Keir Fraser]

On 18/05/2010 12:04, "Tim Deegan" <Tim.Deegan@eu.citrix.com> wrote:

>> 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. :)

If I previously replied positively about this patch, it's because I forgot
about the above PAE restriction.

 -- Keir

Re: Re: one question to p2m table entry type

[Jeremy Fitzhardinge]

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

RE: Re: one question to p2m table entry type

[Jiang, Yunhong]

Oops, sorry, I should notice the (must be 0) :$

--jyh

>-----Original Message-----
>From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
>Sent: Wednesday, May 19, 2010 2:32 AM
>To: Tim Deegan
>Cc: Jiang, Yunhong; xen-devel@lists.xensource.com; 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