From: Ralf Baechle <ralf@linux-mips.org>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH v5] Virtual memory size detection for 64 bit MIPS CPUs
Date: Tue, 2 Feb 2010 14:01:53 +0100 [thread overview]
Message-ID: <20100202130153.GB10837@linux-mips.org> (raw)
In-Reply-To: <1265107061-18355-1-git-send-email-guenter.roeck@ericsson.com>
On Tue, Feb 02, 2010 at 02:37:41AM -0800, Guenter Roeck wrote:
Pretty good, let the nitpicking start :-)
> diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h
> index 1f4df64..284eb55 100644
> --- a/arch/mips/include/asm/cpu-features.h
> +++ b/arch/mips/include/asm/cpu-features.h
> @@ -209,6 +209,9 @@
> # ifndef cpu_has_64bit_addresses
> # define cpu_has_64bit_addresses 1
> # endif
> +# ifndef cpu_vmbits
> +# define cpu_vmbits cpu_data[0].vmbits
> +# endif
> #endif
For 32-bit kernels we probably should fix cpu_vmbits to 31.
#ifdef CONFIG_64BIT
# ifndef cpu_vmbits
# define cpu_vmbits cpu_data[0].vmbits
# define __NEED_VMBITS
# endif
#else
# #define cpu_vmbits 31
#endif
> #if defined(CONFIG_CPU_MIPSR2_IRQ_VI) && !defined(cpu_has_vint)
> diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
> index 1260443..3c694bc 100644
> --- a/arch/mips/include/asm/cpu-info.h
> +++ b/arch/mips/include/asm/cpu-info.h
> @@ -58,6 +58,7 @@ struct cpuinfo_mips {
> struct cache_desc tcache; /* Tertiary/split secondary cache */
> int srsets; /* Shadow register sets */
> int core; /* physical core number */
> + int vmbits; /* Virtual memory size in bits */
#ifdef __NEED_VMBITS
int vmbits; /* Virtual memory size in bits */
#endif
To do for a later separate patch - minimize the sizes of all cpuinfo_mips
members; int is overkill for many members.
> #if defined(CONFIG_MIPS_MT_SMP) || defined(CONFIG_MIPS_MT_SMTC)
> /*
> * In the MIPS MT "SMTC" model, each TC is considered
> diff --git a/arch/mips/include/asm/pgtable-64.h b/arch/mips/include/asm/pgtable-64.h
> index 9cd5089..8eda30b 100644
> --- a/arch/mips/include/asm/pgtable-64.h
> +++ b/arch/mips/include/asm/pgtable-64.h
> @@ -110,7 +110,9 @@
> #define VMALLOC_START MAP_BASE
> #define VMALLOC_END \
> (VMALLOC_START + \
> - PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE - (1UL << 32))
> + min(PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE, \
> + (1UL << cpu_vmbits)) - (1UL << 32))
> +
This overlaps with other allocations near the top - yes, we've been living
dangerous but with bottom up allocations a conflict was very, very unlikely.
Dealing with them in a sane way in the VMALLOC_END macro definition is hard,
so I suggest changing the definition to something like:
extern unsigned long vmalloc_end;
#define VMALLOC_START MAP_BASE
#define VMALLOC_END vmalloc_end
And initialize the value of vmalloc_end in something like the mm section of
arch/mips/kernel/traps.c:per_cpu_trap_init().
There you can also ensure the value of vmalloc_end is <= FIXADDR_START.
Finally probing can be used to fix yet another sin. For 64-bit kernels
arch/mips/include/asm/processor.h defines TASK_SIZE:
#define TASK_SIZE 0x10000000000UL
This should turn into something like.
#define TASK_SIZE (1UL << vmbits)
This is also why I sugget to keep vmbits as 31, not 32. Hello S390 :-)
> +static inline void cpu_set_vmbits(struct cpuinfo_mips *c)
> +{
> + if (cpu_has_64bits) {
> + write_c0_entryhi(0x3ffffffffffff000ULL);
> + back_to_back_c0_hazard();
> + c->vmbits = fls64(read_c0_entryhi() & 0x3ffffffffffff000ULL);
> + } else
> + c->vmbits = 32;
> +}
With my changes suggested above this would need changing to something like:
static inline void cpu_set_vmbits(struct cpuinfo_mips *c)
{
if (__NEED_VMBITS) {
write_c0_entryhi(0x3ffffffffffff000ULL);
back_to_back_c0_hazard();
c->vmbits = fls64(read_c0_entryhi() & 0x3ffffffffffff000ULL);
return;
}
BUG();
}
> #define R4K_OPTS (MIPS_CPU_TLB | MIPS_CPU_4KEX | MIPS_CPU_4K_CACHE \
> | MIPS_CPU_COUNTER)
>
> @@ -967,6 +977,8 @@ __cpuinit void cpu_probe(void)
> c->srsets = ((read_c0_srsctl() >> 26) & 0x0f) + 1;
> else
> c->srsets = 1;
> +
> + cpu_set_vmbits(c);
I think a name like cpu_probe_vmbits() would be clearer.
Thanks,
Ralf
next prev parent reply other threads:[~2010-02-02 13:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-02 10:37 [PATCH v5] Virtual memory size detection for 64 bit MIPS CPUs Guenter Roeck
2010-02-02 13:01 ` Ralf Baechle [this message]
2010-02-02 13:05 ` Dmitri Vorobiev
2010-02-02 13:10 ` Ralf Baechle
2010-02-02 13:34 ` Dmitri Vorobiev
2010-02-02 13:46 ` Ralf Baechle
2010-02-02 13:49 ` Dmitri Vorobiev
2010-02-02 16:03 ` Guenter Roeck
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=20100202130153.GB10837@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=guenter.roeck@ericsson.com \
--cc=linux-mips@linux-mips.org \
/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.