From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2 of 3] x86/mm: Teach paging to page
 table-based p2m
Date: Thu, 15 Mar 2012 17:34:47 +0000
Message-ID: <CB87D8B7.3BB38%keir@xen.org>
References: <20120315172145.GE12366@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20120315172145.GE12366@ocelot.phlegethon.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tim Deegan <tim@xen.org>, Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, Tim Deegan <Tim.Deegan@citrix.com>, andres@gridcentric.ca, wei.wang2@amd.com, hongkaixing@huawei.com, adin@gridcentric.ca
List-Id: xen-devel@lists.xenproject.org

On 15/03/2012 17:21, "Tim Deegan" <tim@xen.org> wrote:

> At 08:46 -0700 on 15 Mar (1331801170), Andres Lagar-Cavilla wrote:
>>> Righto.  In that case, I'd be happy with just clipping MFNs and not
>>> trying to unpack them.  But I think it should happen in the main
>>> pte-building macros, not scattered around the p2m code.  It should just
>>> be a matter of using PADDR_MASK in the right place.
>> 
>> Something along these lines? (RFC, not tested yet)
>> Andres
>> 
>>  /* Construct a pte from a pfn and access flags. */
>>  #define l1e_from_pfn(pfn, flags)   \
>> -    ((l1_pgentry_t) { ((intpte_t)(pfn) << PAGE_SHIFT) | put_pte_flags(flags)
>> })
>> +    ((l1_pgentry_t) { ((intpte_t)((pfn) & (PADDR_MASK >> PAGE_SHIFT)) <<   \
>> +                        PAGE_SHIFT) | put_pte_flags(flags) })
> 
> Yes, that's the idea.  I think
> 
>> +    ((l1_pgentry_t) { (((intpte_t)(pfn) << PAGE_SHIFT) & PADDR_MASK) \
>> +                       | put_pte_flags(flags) })
> 
> is a little neater, maybe?
> 
> In any case, I'd like Keir's ack on this, since it will affect all the
> PV pagetable code too (hopefully in a trivial and correct way).

Fine by me. I don't think any existing users should be intentionally
stuffing non-address bits into a pte via the pfn parameter of a
pte-constructor. I wonder though whether you should have your own
constructor, or wrapper round the generic constructor, for laundering your
filthy nasty pfns? ;-)

 -- Keir

> Tim.