All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	npiggin@suse.de, hugh@veritas.com, rdreier@cisco.com,
	jbarnes@virtuousgeek.org, jeremy@goop.org, arjan@infradead.org,
	linux-kernel@vger.kernel.org, venkatesh.pallipadi@intel.com,
	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 12:07:59 -0800	[thread overview]
Message-ID: <20081216120759.ef11cde8.akpm@linux-foundation.org> (raw)
In-Reply-To: <20081112212900.578371000@intel.com>

On Wed, 12 Nov 2008 13:26:52 -0800
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> wrote:

> Hookup remap_pfn_range and vm_insert_pfn and corresponding copy and free
> routines with reserve and free tracking.
> 
> reserve and free here only takes care of non RAM region mapping. For RAM
> region, driver should use set_memory_[uc|wc|wb] to set the cache type and
> then setup the mapping for user pte. We can bypass below
> reserve/free in that case.
> 
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> 
> ---
>  arch/x86/include/asm/pgtable.h |   10 ++
>  arch/x86/mm/pat.c              |  201 +++++++++++++++++++++++++++++++++++++++++
>  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.

> +{
> +	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.

> +	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?

> +		"%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.

> +			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!

> +			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?

> +			"%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

> +		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.
	
> +	}
> +
> +	return retval;
> +}
> +
>
> ...
>

  reply	other threads:[~2008-12-16 20:09 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 [this message]
2008-12-16 23:19     ` Pallipadi, Venkatesh
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=20081216120759.ef11cde8.akpm@linux-foundation.org \
    --to=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 \
    --cc=venkatesh.pallipadi@intel.com \
    /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.