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

[Tim Deegan <tim@xxxxxxx>]

At 22:15 -0500 on 29 Feb (1330553757), Andres Lagar-Cavilla wrote:
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -53,6 +53,20 @@
>  #define P2M_BASE_FLAGS \
>          (_PAGE_PRESENT | _PAGE_USER | _PAGE_DIRTY | _PAGE_ACCESSED)
>  
> +#ifdef __x86_64__
> +/* l1e_from_pfn is not designed to have INVALID_MFN stored. The 0xff..ff
> + * value tramples over the higher-order bits used for flags (NX, p2mt, 
> + * etc.) This happens for paging entries. Thus we do this clip/unclip
> + * juggle for l1 entries only (no paging superpages!) */
> +#define EFF_MFN_WIDTH       (PADDR_BITS-PAGE_SHIFT) /* 40 bits */
> +#define clipped_mfn(mfn)    ((mfn) & ((1UL << EFF_MFN_WIDTH) - 1))
> +#define unclip_mfn(mfn)     (((mfn) == clipped_mfn(INVALID_MFN)) ? \
> +                                INVALID_MFN : (mfn))
> +#else
> +#define clipped_mfn(mfn)    (mfn)
> +#define unclip_mfn(mfn)     (mfn)
> +#endif /* __x86_64__ */

Hmmm.  If we need to have this, we should probably have it in the main
l*_from_pfn and l*_get_pfn code rather than needing to scatter it around
in the callers.  And we need a check in the e820 map to make sure we
don't ever use MFN 0xffffffff (once CPUs start supporting it).

The alternative would be to add another type so we don't have to store
INVALID_MFN in p2m_ram_paging_in entries. 

Cheers,

Tim.

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