login
Search
I don't know. Is it? It's what linux/ioport.h:struct resource uses to
hold "start" and "end", which presumably means its intended to hold
Not an option:
config X86_PAE
def_bool n
prompt "PAE (Physical Address Extension) Support"
depends on X86_32 && !HIGHMEM4G
select RESOURCES_64BIT
And if you don't enable RESOURCES_64BIT, then I guess it's reasonable
I had that originally, but someone (hpa?) suggested resource_size_t.
The sad thing is that most users don't really care; they're either
64-bit anyway, or immediately truncate the result to 32-bit.
"Properly" would be to define a phys_addr_t which can always represent a
physical address. We have one in x86-land, but I hesitate to add it for
(u64) cast, I guess.
J
--
On Thu, 07 Aug 2008 15:10:11 -0700 Yes, but resource_size_t is for IO addressing, not for memory addressing. Lots of X86_32 machines can happily support 32-bit physical addresses err, OK, that was a bit arbitrary of us. Oh well, scrub the above assertion. Then again, do all architectures disallow 32-bit resource_size_t on hm. It is a distinct and singular concept - it makes sense to have a nope ;) We don't know what type u64 has - some architectures use `unsigned long' (we might fix this soon). For now, a full cast to `unsigned long long' is needed. --
Really? The resource tree treats normal memory as just another
resource. Is it expected that you could have usable memory not
represented by /proc/iomem?
Hm, looks like memory hotplug assumes that resource_size_t is always
64-bits, but the e820->resource conversion simply skips over-large
x86 and ppc were the only archs to touch it; they otherwise use the
default of "default 64BIT".
I didn't look at the ppc use case. I wasn't terribly concerned about
Yes. We had to be particularly careful with it on x86 because of all
the problems it's caused, but it is a generally useful thing to be able
to talk about.
Shall we go with just using plain u64 (or unsigned long long if we want
a really consistent type) in the meantime, and then waffle about
introducing a new type everywhere?
Or we could redefine resource_size_t to be big enough to refer to any
Yep.
J
--
On Thu, 07 Aug 2008 16:45:12 -0700 We could do typedef resource_size_t jeremy_thing_t; for now and worry about it later if the need arises, perhaps. --
OK, I'll revise and repost.
Hm, curiously, the two arches which care most about this issue (x86 and
powerpc) already have phys_addr_t...
I guess we don't want CONFIG_ARCH_HAVE_PHYS_ADDR_T...
J
--
PFN_PHYS, as its name suggests, turns a pfn into a physical address.
However, it is a macro which just operates on its argument without
modifying its type. pfns are typed unsigned long, but an unsigned
long may not be long enough to hold a physical address (32-bit systems
with more than 32 bits of physcial address).
Make sure we cast to phys_addr_t to return a complete result.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
---
arch/m32r/mm/discontig.c | 2 +-
include/asm-x86/xen/page.h | 4 ++--
include/linux/pfn.h | 6 +++++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff -r 6b03eb6361dd arch/m32r/mm/discontig.c
--- a/arch/m32r/mm/discontig.c Mon Aug 11 11:19:24 2008 -0700
+++ b/arch/m32r/mm/discontig.c Mon Aug 11 11:20:07 2008 -0700
@@ -112,9 +112,9 @@
initrd_start, INITRD_SIZE);
} else {
printk("initrd extends beyond end of memory "
- "(0x%08lx > 0x%08lx)\ndisabling initrd\n",
+ "(0x%08lx > 0x%08llx)\ndisabling initrd\n",
INITRD_START + INITRD_SIZE,
- PFN_PHYS(max_low_pfn));
+ (unsigned long long)PFN_PHYS(max_low_pfn));
initrd_start = 0;
}
diff -r 6b03eb6361dd include/asm-x86/xen/page.h
--- a/include/asm-x86/xen/page.h Mon Aug 11 11:19:24 2008 -0700
+++ b/include/asm-x86/xen/page.h Mon Aug 11 11:20:07 2008 -0700
@@ -76,13 +76,13 @@
static inline xmaddr_t phys_to_machine(xpaddr_t phys)
{
unsigned offset = phys.paddr & ~PAGE_MASK;
- return XMADDR(PFN_PHYS((u64)pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+ return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
}
static inline xpaddr_t machine_to_phys(xmaddr_t machine)
{
unsigned offset = machine.maddr & ~PAGE_MASK;
- return XPADDR(PFN_PHYS((u64)mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+ return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
}
/*
diff -r 6b03eb6361dd include/linux/pfn.h
--- a/include/linux/pfn.h Mon Aug 11 ...Add a kernel-wide "phys_addr_t" which is guaranteed to be able to hold
any physical address. By default it equals the word size of the
architecture, but a 32-bit architecture can set ARCH_PHYS_ADDR_T_64BIT
if it needs a 64-bit phys_addr_t.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff -r 4909b40dbdc5 arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri Aug 08 13:40:52 2008 -0700
+++ b/arch/powerpc/Kconfig Mon Aug 11 10:32:52 2008 -0700
@@ -21,6 +21,9 @@
config PPC_MERGE
def_bool y
+
+config ARCH_PHYS_ADDR_T_64BIT
+ def_bool PPC64 || PHYS_64BIT
config MMU
bool
diff -r 4909b40dbdc5 arch/x86/Kconfig
--- a/arch/x86/Kconfig Fri Aug 08 13:40:52 2008 -0700
+++ b/arch/x86/Kconfig Mon Aug 11 10:32:53 2008 -0700
@@ -1002,6 +1002,9 @@
has the cost of more pagetable lookup overhead, and also
consumes more pagetable space per process.
+config ARCH_PHYS_ADDR_T_64BIT
+ def_bool X86_64 || X86_PAE
+
# Common NUMA Features
config NUMA
bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
diff -r 4909b40dbdc5 include/asm-powerpc/types.h
--- a/include/asm-powerpc/types.h Fri Aug 08 13:40:52 2008 -0700
+++ b/include/asm-powerpc/types.h Mon Aug 11 10:32:53 2008 -0700
@@ -48,13 +48,6 @@
typedef __vector128 vector128;
-/* Physical address used by some IO functions */
-#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
-typedef u64 phys_addr_t;
-#else
-typedef u32 phys_addr_t;
-#endif
-
#ifdef __powerpc64__
typedef u64 dma_addr_t;
#else
diff -r 4909b40dbdc5 include/asm-x86/page_32.h
--- a/include/asm-x86/page_32.h Fri Aug 08 13:40:52 2008 -0700
+++ b/include/asm-x86/page_32.h Mon Aug 11 10:32:53 2008 -0700
@@ -33,7 +33,6 @@
typedef u64 pudval_t;
typedef u64 pgdval_t;
typedef u64 pgprotval_t;
-typedef u64 phys_addr_t;
typedef union {
struct {
@@ -54,7 +53,6 @@
typedef unsigned ...I've been wondering for some time why can't we make phys_addr_t and resource_size_t the same thing... I don't like having two ARCH_* thing especially since I believe the one for resources is already what we want. --
I made the same argument, but Andrew thinks they're conceptually
distinct. It is theoretically possible you might have a system with >4G
memory, but all io resources < 4G, so you'd have resource_size_t
32-bits, while having 64-bit physical addresses. You can configure such
a thing, but I don't know if it's 1) useful or 2) used.
J
--
Are we sure resource_size_t is -never- used to represent memory ? I though it was on some platforms.... Ben. --
On x86 it's optionally used to put memory in the resource tree, but if
the memory is larger than can be held in resource_size_t it simply skips
it. Don't know about elsewhere.
J
--
That sounds like a good enough reason to not separate the two concepts.. Ben. --
The resource_size_t situation is obscure. I'd be happy to just remove
its config, use my patch and typedef phys_addr_t resource_size_t.
J
--
I have no objection there as far as powerpc is concerned. Ben. --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |