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
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-May-18 18:32 UTC
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@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-May-19 03:02 UTC
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@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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel