This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] x86-64 machine_to_phys vs NX bit

To: "Rik van Riel" <riel@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] x86-64 machine_to_phys vs NX bit
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Fri, 25 Aug 2006 07:46:35 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 25 Aug 2006 07:47:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbIThvco556b9roQ32C9hzQss15PgABlbhg
Thread-topic: [Xen-devel] x86-64 machine_to_phys vs NX bit
Rik van Riel wrote:
> Keir Fraser wrote:
>> On 24/8/06 8:25 pm, "Rik van Riel" <riel@xxxxxxxxxx> wrote:
>>> Say, something like the following?
>>> -    paddr_t phys = mfn_to_pfn(machine >> PAGE_SHIFT);
>>> +    paddr_t phys = mfn_to_pfn((machine >> PAGE_SHIFT) &
>>> I'm still thinking I may have missed something in the code
>>> somewhere, but I've been looking at this for over an hour now
>>> and can't seem to find it...
>>> Any ideas?
>> Your suggested patch looks reasonable but it'd be good to find out
>> why this hasn't caused us problems. For example, perhaps
>> supported_pte_mask doesn't include PAGE_NX, so we're never setting
>> the NX bit on 64-bit PTEs? 
> We do set the NX bit.  Including on vmalloced pages...
>> That must be worth checking out, possibly also tracing
>> machine_to_phys to find out where that bit 63 goes -- I agree that it
>> looks like mfn_to_pfn() shouldn't work if bit63 is set in the
>> 'maddr' argument.
> Absolutely :)

I agree, and I'm wondering why we don't have the same problem on i386?
To me it basically does the same thing.

static inline unsigned long long pte_val(pte_t x)
        unsigned long long ret;

        if (x.pte_low) {
                ret = x.pte_low | (unsigned long long)x.pte_high << 32;
                ret = machine_to_phys(ret) | 1;
        } else {
                ret = 0;
        return ret;

Intel Open Source Technology Center

Xen-devel mailing list