From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Byrne Subject: Re: x86-64 machine_to_phys vs NX bit Date: Mon, 13 Nov 2006 12:45:45 -0800 Message-ID: <4558D979.9000902@hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel , Jan Beulich List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 13/11/06 8:07 am, "Jan Beulich" wrote: > >>> There was a bug in my previous patch. (There's nothing like trying to >>> get to sleep and realizing you've screwed up.) The x86 pae >>> PHYSICAL_PAGE_MASK I defined was incorrect because PAGE_MASK was only a >>> long. I hope I haven't done anything else wrong. >> I don't think this is correct - machine_to_phys() translates a machine address >> to a physical one, and in that translation the upper bits matter only as much >> as mfn_to_pfn() should return an invalid indicator if any of them is set. In >> turn, >> it should be the caller's responsibility to make sure the NX bit (and any >> potential >> other one being set beyond bit 52) gets masked off *before* calling this >> function. (Specifically, the preserving of the lower bits is to properly >> translate >> a non-page aligned address, not to preserve attribute bits read from a page >> table entry). > > Yes, we should keep the old machine_to_phys() definition and rename John's > new version as pte_machine_to_phys(). The latter should be used in all > contexts where machine_to_phys() currently operates on a pte (that's most of > its uses, actually). This is a worthwhile cleanup and clarification. Could > you respin the patch, John? > > Thanks, > Keir > > > I've made the change. I'll send it out after I've built and tested it. John