Messages in this thread |  | | | Date | Wed, 22 Dec 2010 10:02:58 -0500 | | From | Konrad Rzeszutek Wilk <> | | Subject | Re: [PATCH 04/10] xen/mmu: For 1-1 mapping, automatically set _PAGE_IOMAP. |
| |
On Tue, Dec 21, 2010 at 02:29:31PM -0800, Jeremy Fitzhardinge wrote: > On 12/21/2010 01:37 PM, Konrad Rzeszutek Wilk wrote: > > This means that for PFNs (specifically: those in any E820 gaps > > or non-RAM E820 regions) that have 1-1 mapping we set the > > _PAGE_IOMAP flag. > > > > Later on we could remove the _PAGE_IOMAP code handling, but > > for right now lets keep this in to not introduce any bisection > > failures across this patchset. > > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > > --- > > arch/x86/xen/mmu.c | 3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > > index 4ba7e4e..bd02e7d 100644 > > --- a/arch/x86/xen/mmu.c > > +++ b/arch/x86/xen/mmu.c > > @@ -832,6 +832,9 @@ static pteval_t pte_pfn_to_mfn(pteval_t val) > > pteval_t flags = val & PTE_FLAGS_MASK; > > unsigned long mfn = pfn_to_mfn(pfn); > > > > + if (mfn == pfn) > > + flags |= _PAGE_IOMAP; > > Why? Does it really make sense to set _PAGE_IOMAP if they just happen > to be the same value?
Yes. Without this, user applications, such as 'dmidecode' cannot get data.
But I think with ditching a bunch of the _PAGE_IOMAP in the xen/mmu.c we can remove this.
I would rather keep this patch as temporary scaffolding and when the other set of patches is ready for the _PAGE_IOMAP, ditch this one.
> > J
|  |