|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] x86/xen: make mfn_to_pfn() work with MFNs that are 1:1 in the p2m
On Fri, 3 Jan 2014, David Vrabel wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
>
> The _PAGE_IOMAP PTE flag is used to indicate that the PTE contains an
> MFN that is an identify frame (1:1) in the p2m. This is so the
> correct conversion of MFN to PFN can be done reading a PTE.
>
> If mfn_to_pfn() returned the correct PFN instead the _PAGE_IOMAP flag
> is not required and can be removed.
>
> In mfn_to_pfn() the PFN found in the M2P is checked in P2M. If the
> two MFNs differ then the MFN is one of three possibilities:
>
> a) its a foreign MFN with an m2p override.
>
> b) it's a foreign MFN with /no/ m2p override.
>
> c) it's a identity MFN.
>
> It is not permitted to call mfn_to_pfn() no a foreign MFN without an
> override was the resulting PFN will not incorrect. We can therefore
> assume case (c) and return PFN == MFN.
>
> [ This patch should probably be split into the Xen-specific parts and
> an x86 patch to remove _PAGE_IOMAP. ]
>
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
> arch/x86/include/asm/pgtable_types.h | 12 +++---
> arch/x86/include/asm/xen/page.h | 18 +++++++---
> arch/x86/mm/init_32.c | 2 +-
> arch/x86/mm/init_64.c | 2 +-
> arch/x86/pci/i386.c | 2 -
> arch/x86/xen/enlighten.c | 2 -
> arch/x86/xen/mmu.c | 58
> +++++-----------------------------
> 7 files changed, 28 insertions(+), 68 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 0ecac25..0b12657 100644
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index b913915..eb11963 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -112,11 +112,18 @@ static inline unsigned long mfn_to_pfn(unsigned long
> mfn)
> pfn = mfn_to_pfn_no_overrides(mfn);
> if (get_phys_to_machine(pfn) != mfn) {
> /*
> - * If this appears to be a foreign mfn (because the pfn
> - * doesn't map back to the mfn), then check the local override
> - * table to see if there's a better pfn to use.
> + * This is either:
> *
> - * m2p_find_override_pfn returns ~0 if it doesn't find anything.
> + * a) a foreign MFN with an override.
> + *
> + * b) a foreign MFN without an override.
> + *
> + * c) an identity MFN that is not in the the p2m.
You have missed a case here:
d) a local MFN with an override
think of blkfront and blkback in the same domain.
However I don't think this case would be affected by the patch.
> + * For (a), look in the m2p overrides. For (b) and
> + * (c) assume identify MFN since mfn_to_pfn() will
> + * only be called on foreign MFNs iff they have
> + * overrides.
> */
> pfn = m2p_find_override_pfn(mfn, ~0);
> }
> @@ -126,8 +133,7 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
> * entry doesn't map back to the mfn and m2p_override doesn't have a
> * valid entry for it.
> */
> - if (pfn == ~0 &&
> - get_phys_to_machine(mfn) == IDENTITY_FRAME(mfn))
> + if (pfn == ~0)
> pfn = mfn;
>
> return pfn;
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |