Re: [Xen-devel] [PATCH 2 of 3] x86/mm: Teach paging to page table-based p2m

[Keir Fraser <keir@xxxxxxx>]

On 15/03/2012 17:21, "Tim Deegan" <tim@xxxxxxx> 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.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel