From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"mingo@elte.hu" <mingo@elte.hu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"npiggin@suse.de" <npiggin@suse.de>,
"hugh@veritas.com" <hugh@veritas.com>,
"rdreier@cisco.com" <rdreier@cisco.com>,
"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
"jeremy@goop.org" <jeremy@goop.org>,
"arjan@infradead.org" <arjan@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [patch 5/8] x86 PAT: Implement track/untrack of pfnmap regions for x86
Date: Tue, 16 Dec 2008 15:19:16 -0800 [thread overview]
Message-ID: <20081216231916.GA1992@linux-os.sc.intel.com> (raw)
In-Reply-To: <20081216120759.ef11cde8.akpm@linux-foundation.org>
On Tue, Dec 16, 2008 at 12:07:59PM -0800, Andrew Morton wrote:
> Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> wrote:
>
> > 2 files changed, 211 insertions(+)
> >
> > Index: tip/arch/x86/mm/pat.c
> > ===================================================================
> > --- tip.orig/arch/x86/mm/pat.c 2008-11-12 09:55:55.000000000 -0800
> > +++ tip/arch/x86/mm/pat.c 2008-11-12 12:06:50.000000000 -0800
> > @@ -596,6 +596,207 @@ void unmap_devmem(unsigned long pfn, uns
> > free_memtype(addr, addr + size);
> > }
> >
> > +int reserve_pfn_range(u64 paddr, unsigned long size, pgprot_t vma_prot)
>
> I don't think the kernel is improved by leaving all these things
> undocumented.
>
> These are interfaces which other architectures might choose to
> implement, so a few words explaining why they exist, what they are
> supposed to do, etc wouldn't hurt.
>
> It would certainly help code reviewers.
Agreed. Will add documentation to the new functions here and update the patch.
>
> > +{
> > + unsigned long flags;
> > + unsigned long want_flags = (pgprot_val(vma_prot) & _PAGE_CACHE_MASK);
> > +
> > + int is_ram = 0;
> > + int id_sz, ret;
>
> The newline in the middle of the definition of locals makes no sense.
Will change.
> > + is_ram = pagerange_is_ram(paddr, paddr + size);
> > +
> > + if (is_ram != 0) {
> > + /*
> > + * For mapping RAM pages, drivers need to call
> > + * set_memory_[uc|wc|wb] directly, for reserve and free, before
> > + * setting up the PTE.
> > + */
> > + WARN_ON_ONCE(1);
> > + return 0;
> > + }
> > +
> > + ret = reserve_memtype(paddr, paddr + size, want_flags, &flags);
> > + if (ret)
> > + return ret;
> > +
> > + if (flags != want_flags) {
> > + free_memtype(paddr, paddr + size);
> > + printk(KERN_INFO
>
> Would KERN_ERR be more appropriate?
OK.
>
> > + "%s:%d map pfn expected mapping type %s for %Lx-%Lx, got %s\n",
> > + current->comm, current->pid,
>
> get_task_comm() is more reliable, but it hardly matters here.
current->comm was used at other places in this file. I should probably change
all of them as a separate cleanup patch.
>
> > + cattr_name(want_flags),
> > + paddr, (unsigned long long)(paddr + size),
>
> Printing the u64 paddr without a cast is OK in arch code (we know that
> u64 is implemented as unsigned long long). But one might choose to
> cast it anyway, to set a good example.
>
> Or one could not bother. But this code does it both ways!
>
Will change.
> > + cattr_name(flags));
> > + return -EINVAL;
> > + }
> > +
> > + /* Need to keep identity mapping in sync */
> > + if (paddr >= __pa(high_memory))
> > + return 0;
> > +
> > + id_sz = (__pa(high_memory) < paddr + size) ?
> > + __pa(high_memory) - paddr :
> > + size;
> > +
> > + if (ioremap_change_attr((unsigned long)__va(paddr), id_sz, flags) < 0) {
> > + free_memtype(paddr, paddr + size);
> > + printk(KERN_INFO
>
> KERN_ERR?
OK.
>
> > + "%s:%d reserve_pfn_range ioremap_change_attr failed %s "
> > + "for %Lx-%Lx\n",
> > + current->comm, current->pid,
> > + cattr_name(flags),
> > + paddr, (unsigned long long)(paddr + size));
>
> ditto
Will do.
>
> > + return -EINVAL;
> > + }
> > + return 0;
> > +}
> > +
> > +void free_pfn_range(u64 paddr, unsigned long size)
> > +{
> > + int is_ram;
> > +
> > + is_ram = pagerange_is_ram(paddr, paddr + size);
> > + if (is_ram == 0)
> > + free_memtype(paddr, paddr + size);
> > +}
> >
> > ...
> >
> > +int track_pfn_vma_new(struct vm_area_struct *vma, pgprot_t prot,
> > + unsigned long pfn, unsigned long size)
> > +{
> > + int retval = 0;
> > + unsigned long i, j;
> > + u64 base_paddr;
> > + u64 paddr;
> > + unsigned long vma_start = vma->vm_start;
> > + unsigned long vma_end = vma->vm_end;
> > + unsigned long vma_size = vma_end - vma_start;
> > +
> > + if (!pat_enabled)
> > + return 0;
> > +
> > + if (is_linear_pfn_mapping(vma)) {
> > + /* reserve the whole chunk starting from vm_pgoff */
> > + paddr = (u64)vma->vm_pgoff << PAGE_SHIFT;
> > + return reserve_pfn_range(paddr, vma_size, prot);
> > + }
> > +
> > + /* reserve page by page using pfn and size */
> > + base_paddr = (u64)pfn << PAGE_SHIFT;
> > + for (i = 0; i < size; i += PAGE_SIZE) {
> > + paddr = base_paddr + i;
> > + retval = reserve_pfn_range(paddr, PAGE_SIZE, prot);
> > + if (retval)
> > + goto cleanup_ret;
> > + }
> > + return 0;
> > +
> > +cleanup_ret:
> > + /* Reserve error: Cleanup partial reservation and return error */
> > + for (j = 0; j < i; j += PAGE_SIZE) {
> > + paddr = base_paddr + j;
> > + free_pfn_range(paddr, PAGE_SIZE);
>
> Could we simply do
>
> free_pfn_range(base_paddr, i * PAGE_SIZE);
>
> here?
>
> If not, then perhaps add a helper function to do this, because that
> loop gets repeated in several places.
>
free_pfn_range(base_paddr, i * PAGE_SIZE);
will not work as free should correspond to reserve granularity. I agree making
this a function should make this cleaner. Will do that in the refresh of this
patch.
Thanks,
Venki
next prev parent reply other threads:[~2008-12-16 23:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 21:26 [patch 0/8] x86 PAT: track pfnmap mappings with remap_pfn_range and vm_insert_pfn Venkatesh Pallipadi
2008-11-12 21:26 ` [patch 1/8] x86 PAT: store vm_pgoff for all linear_over_vma_region mappings Venkatesh Pallipadi
2008-11-12 21:26 ` [patch 2/8] x86 PAT: set VM_PFNMAP flag in vm_insert_pfn Venkatesh Pallipadi
2008-11-12 23:23 ` Nick Piggin
2008-11-13 0:02 ` Pallipadi, Venkatesh
2008-11-13 3:44 ` Nick Piggin
2008-11-13 18:47 ` Pallipadi, Venkatesh
2008-11-14 2:05 ` Nick Piggin
2008-11-14 21:35 ` Pallipadi, Venkatesh
2008-11-17 2:30 ` Nick Piggin
2008-11-18 21:37 ` Ingo Molnar
2008-11-20 23:42 ` Pallipadi, Venkatesh
2008-11-21 0:50 ` Nick Piggin
2008-11-15 7:38 ` Benjamin Herrenschmidt
2008-11-12 21:26 ` [patch 3/8] x86 PAT: Add follow_pfnmp_pte routine to help tracking pfnmap pages Venkatesh Pallipadi
2008-11-12 23:27 ` Nick Piggin
2008-11-12 23:54 ` Pallipadi, Venkatesh
2008-11-12 21:26 ` [patch 4/8] x86 PAT: hooks in generic vm code to help archs to track pfnmap regions Venkatesh Pallipadi
2008-12-16 19:57 ` Andrew Morton
2008-12-16 20:07 ` Pallipadi, Venkatesh
2008-12-16 20:13 ` Andrew Morton
2008-11-12 21:26 ` [patch 5/8] x86 PAT: Implement track/untrack of pfnmap regions for x86 Venkatesh Pallipadi
2008-12-16 20:07 ` Andrew Morton
2008-12-16 23:19 ` Pallipadi, Venkatesh [this message]
2008-11-12 21:26 ` [patch 6/8] x86 PAT: change pgprot_noncached to uc_minus instead of strong uc Venkatesh Pallipadi
2008-11-12 21:26 ` [patch 7/8] x86 PAT: add pgprot_writecombine() interface for drivers Venkatesh Pallipadi
2008-11-12 21:26 ` [patch 8/8] x86 PAT: update documentation to cover pgprot and remap_pfn related changes Venkatesh Pallipadi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081216231916.GA1992@linux-os.sc.intel.com \
--to=venkatesh.pallipadi@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=hugh@veritas.com \
--cc=jbarnes@virtuousgeek.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=rdreier@cisco.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.