* Re: smp8634 add memory at dram1
From: david @ 2007-11-14 12:36 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David Kuk, linux-mips
In-Reply-To: <20071114110426.GA19693@linux-mips.org>
Quoting Ralf Baechle <ralf@linux-mips.org>:
>
> I don't know what processor core Sigma is using in this SOC. In case its a
> 64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
> kernel, it's much less painful than highmem.
>
> Ralf
>
>
It is a MIPS 4KEc core.
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero()
From: Franck Bui-Huu @ 2007-11-14 12:34 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20071114115807.GL8363@networkno.de>
Thiemo Seufer wrote:
> In general we do (think of stack unwinding etc.). I believe this
> implementation should move to C, as it doesn't need an assembler
> implementation:
>
> void *memset (void *s, int c, kernel_size_t n)
> {
> __fill_user(s, c, n);
> return s;
> }
>
> It looks much nicer that way. :-)
>
Sure but memset.S was a really good place to implement memset(), wasn't
it ?
And since the implementation should have been trivial, I thought it was
ok to implement in assembly.
Ok, I'll look for another place.
Thanks,
Franck
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero()
From: Thiemo Seufer @ 2007-11-14 11:58 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <473AB0B6.2070208@gmail.com>
Franck Bui-Huu wrote:
> Thiemo Seufer wrote:
> > Franck Bui-Huu wrote:
> >> /*
> >> - * memset(void *s, int c, size_t n)
> >> + * An outline version of memset, which should be used either by gcc or
> >> + * by assembly code.
> >> + */
> >> +NESTED(memset, 24, ra)
> >> + PTR_ADDU sp, sp, -24
> >> + LONG_S a0, 16(sp)
> >> + LONG_S ra, 20(sp)
> >> + jal __fill_user
> >> + LONG_L v0, 16(sp)
> >> + LONG_L ra, 20(sp)
> >> + PTR_ADDU sp, sp, 24
> >> + jr ra
> >> +END(memset)
> >
> > This will break on 64bit kernels.
> >
>
> Is the following correct ?
>
> NESTED(memset, 16, ra)
> PTR_ADDU sp, sp, -16
> LONG_S a0, 8(sp)
> LONG_S ra, 16(sp)
> jal __fill_user
> LONG_L v0, 8(sp)
> LONG_L ra, 16(sp)
> PTR_ADDU sp, sp, 16
> jr ra
> END(memset)
>
> I know it doesn't respect any mips ABI but in this case do
> we really care ?
In general we do (think of stack unwinding etc.). I believe this
implementation should move to C, as it doesn't need an assembler
implementation:
void *memset (void *s, int c, kernel_size_t n)
{
__fill_user(s, c, n);
return s;
}
It looks much nicer that way. :-)
Thiemo
^ permalink raw reply
* Re: smp8634 add memory at dram1
From: Ralf Baechle @ 2007-11-14 11:04 UTC (permalink / raw)
To: David Kuk; +Cc: linux-mips
In-Reply-To: <473AB56B.2070107@entone.com>
On Wed, Nov 14, 2007 at 04:44:27PM +0800, David Kuk wrote:
> After study about the memory configuration of sigma smp8634, i found
> some difficult to accomplish the task.
>
> so my question is if have two 128MB ram separately under dram0 and dram1
> controller, where dram0 for linux and dram1 for video decoding. Now the
> situation is the memory for linux is not enough and video decoding can
> not use all of it's 128MB at dram1, what we plan to do is to share 64MB
> at dram1 to the linux kernel as high memory, and only reserved 64MB at
> dram1 for the video decoding.
>
> first, in MIPS architecture, we found that the kseg0 and kseg1 are
> mapped to 0x00000000-0x20000000, which include only dram0 controller, so
> we wish to add the dram1 memory manually to the kernel using function
> add_memory_region at setup.c , after booting up result the warning that
> the memory larger than 512 need to configured the kernel support high
> memory.
>
> then when we configure the kernel to support high memory at menu
> configure, the kernel when booting up will remind us our CPU do not
> support high memory due to cache aliases.
This is really a software restriction. I originally developped highmem for
MIPS on a Sibyte SB1250 which doesn't suffer from aliases so I didn't even
attempt to solve the cache aliasing issue. The other platforms on whic
highmem used to be used was the E9000 family but it seem by now the users
of these platforms have all moved to full 64-bit kernels, so aside fo the
implementation restrictions has also started to bitrot a little.
What would be necessary to get it to work is to flush the page from cache at
kunmap() rsp. kunmap_atomic() time. That should do the trick though there
are significant further optimizations possible.
An alterantive to solve the aliasing issue would be to increase the
page size to 16K. Again, the combination of highmem and 16K pages is
untested.
I don't know what processor core Sigma is using in this SOC. In case its a
64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
kernel, it's much less painful than highmem.
Ralf
^ permalink raw reply
* smp8634 add memory at dram1
From: David Kuk @ 2007-11-14 8:44 UTC (permalink / raw)
To: linux-mips
After study about the memory configuration of sigma smp8634, i found
some difficult to accomplish the task.
so my question is if have two 128MB ram separately under dram0 and dram1
controller, where dram0 for linux and dram1 for video decoding. Now the
situation is the memory for linux is not enough and video decoding can
not use all of it's 128MB at dram1, what we plan to do is to share 64MB
at dram1 to the linux kernel as high memory, and only reserved 64MB at
dram1 for the video decoding.
first, in MIPS architecture, we found that the kseg0 and kseg1 are
mapped to 0x00000000-0x20000000, which include only dram0 controller, so
we wish to add the dram1 memory manually to the kernel using function
add_memory_region at setup.c , after booting up result the warning that
the memory larger than 512 need to configured the kernel support high
memory.
then when we configure the kernel to support high memory at menu
configure, the kernel when booting up will remind us our CPU do not
support high memory due to cache aliases.
Both way will lead the linux can not boot up normally, so what should we
do, is there any mis-understanding about the hardware implementation or
MIPS design? \
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero()
From: Franck Bui-Huu @ 2007-11-14 8:24 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20071111130130.GB8363@networkno.de>
Thiemo Seufer wrote:
> Franck Bui-Huu wrote:
>> /*
>> - * memset(void *s, int c, size_t n)
>> + * An outline version of memset, which should be used either by gcc or
>> + * by assembly code.
>> + */
>> +NESTED(memset, 24, ra)
>> + PTR_ADDU sp, sp, -24
>> + LONG_S a0, 16(sp)
>> + LONG_S ra, 20(sp)
>> + jal __fill_user
>> + LONG_L v0, 16(sp)
>> + LONG_L ra, 20(sp)
>> + PTR_ADDU sp, sp, 24
>> + jr ra
>> +END(memset)
>
> This will break on 64bit kernels.
>
Is the following correct ?
NESTED(memset, 16, ra)
PTR_ADDU sp, sp, -16
LONG_S a0, 8(sp)
LONG_S ra, 16(sp)
jal __fill_user
LONG_L v0, 8(sp)
LONG_L ra, 16(sp)
PTR_ADDU sp, sp, 16
jr ra
END(memset)
I know it doesn't respect any mips ABI but in this case do
we really care ?
thanks.
Franck
^ permalink raw reply
* Re: hello
From: Freddy Spierenburg @ 2007-11-14 7:55 UTC (permalink / raw)
To: David Kuk; +Cc: linux-mips
In-Reply-To: <473A72DC.1020900@entone.com>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
Hi David,
On Wed, Nov 14, 2007 at 12:00:28PM +0800, David Kuk wrote:
> I am a new guy for both linux and mips, may i ask questions here ??
If your question is Linux kernel and MIPS related, go ahead! You
don't need to ask if you may ask a question, just fire it up!
If it is more user-land related in the sense of how can I unpack
a tarball or the like, you might wander of to some other places
like http://www.linuxquestions.org/.
As a general rule of thumb; look at the small description of a
list on a page like:
http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists
and see what kind of questions other people ask on the list
archive: http://www.linux-mips.org/archives/
This is true not only for the linux-mips community, but for the
rest too. Good luck!
--
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* hello
From: David Kuk @ 2007-11-14 4:00 UTC (permalink / raw)
To: linux-mips
Hi all
I am a new guy for both linux and mips, may i ask questions here ??
THX
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROUND_WAR
From: Kevin D. Kissell @ 2007-11-13 22:49 UTC (permalink / raw)
To: Ralf Baechle
Cc: Franck Bui-Huu, Andrew Haley, David Daney, linux-mips,
Richard Sandiford, gcc
In-Reply-To: <20071113150820.GB6582@linux-mips.org>
> > True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> > systems (which I know you work on) where it's even possible for the stack
> > *not* to have exec permissions, since the classical MIPS MMU gives
> > execute permission to any page that is readable.
>
> Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take
> care of I-cache coherency. So it's somewhat beneficial even in absence of
> a protection bit in the actual TLB hardware.
That depends on just what the consequences of I-cache incoherence might be.
Without help from the MMU, the kernel cannot *know* that a given location
isn't in the I-cache, because a program can always compute a pointer-to-function
to an arbitrary address and dereference it successfully so long as the location
is readable. If it's only the user who does this that will suffer as a result of
I-cache incoherence, one can argue that it serves him right. But if it can screw
up the execution of the kernel, or other user processes, I think we have to
assume the worst.
> Some of these performance optimizations are impossible because the kernel
> can't have definate knowledge that certain addresses have never entered the
> I-cache.
Sad but true.
Regards,
Kevin K.
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROUND_WAR
From: Kevin D. Kissell @ 2007-11-13 22:49 UTC (permalink / raw)
To: Ralf Baechle
Cc: Franck Bui-Huu, Andrew Haley, David Daney, linux-mips,
Richard Sandiford, gcc
In-Reply-To: <20071113150820.GB6582@linux-mips.org>
> > True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> > systems (which I know you work on) where it's even possible for the stack
> > *not* to have exec permissions, since the classical MIPS MMU gives
> > execute permission to any page that is readable.
>
> Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take
> care of I-cache coherency. So it's somewhat beneficial even in absence of
> a protection bit in the actual TLB hardware.
That depends on just what the consequences of I-cache incoherence might be.
Without help from the MMU, the kernel cannot *know* that a given location
isn't in the I-cache, because a program can always compute a pointer-to-function
to an arbitrary address and dereference it successfully so long as the location
is readable. If it's only the user who does this that will suffer as a result of
I-cache incoherence, one can argue that it serves him right. But if it can screw
up the execution of the kernel, or other user processes, I think we have to
assume the worst.
> Some of these performance optimizations are impossible because the kernel
> can't have definate knowledge that certain addresses have never entered the
> I-cache.
Sad but true.
Regards,
Kevin K.
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Andrew Pinski @ 2007-11-13 22:11 UTC (permalink / raw)
To: Ralf Baechle
Cc: Franck Bui-Huu, Andrew Haley, David Daney, linux-mips,
Richard Sandiford, gcc
In-Reply-To: <20071113150146.GC7650@linux-mips.org>
On 11/13/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> Old versions of glibc were probable the most notorious users of trampolines.
> Objective C also generates them. Since a cacheflush that is a syscall is
> required performance is less than great.
No Objective-C does not generate them. Objective-C returns the exact
function pointer back. Now libffi generates trampolines.
-- Pinski
^ permalink raw reply
* VDSO on mips (was Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR)
From: Franck Bui-Huu @ 2007-11-13 21:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <cda58cb80711130514x16356ea3x4069616c9ee3caac@mail.gmail.com>
Franck Bui-Huu wrote:
>
> I started to add vdso support for MIPS a couple months ago, but
> it's in a very early stage and I unfortunately haven't time to finish
> it. I can send it to you if you want.
>
Here it is. As I said it far from complete but it might help.
Franck
--- 8< ---
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 2fd96d9..01d700c 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -6,11 +6,13 @@ extra-y := head.o init_task.o vmlinux.lds
obj-y += cpu-probe.o branch.o entry.o genex.o irq.o process.o \
ptrace.o reset.o semaphore.o setup.o signal.o syscall.o \
- time.o topology.o traps.o unaligned.o
+ time.o topology.o traps.o unaligned.o vdso.o
binfmt_irix-objs := irixelf.o irixinv.o irixioctl.o irixsig.o \
irix5sys.o sysirix.o
+obj-$(CONFIG_32BIT) += vdso32/
+
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-$(CONFIG_MODULES) += mips_ksyms.o module.o
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
new file mode 100644
index 0000000..281b7ce
--- /dev/null
+++ b/arch/mips/kernel/vdso.c
@@ -0,0 +1,52 @@
+#include <linux/init.h>
+
+typedef struct {
+ unsigned long id;
+ unsigned long vdso_base;
+} mm_context_t;
+
+
+static int vdso_enabled __read_mostly = 1;
+
+static int __init vdso_setup(char *s)
+{
+ vdso_enabled = simple_strtol(s, NULL, 0);
+ return 1;
+}
+__setup("vdso=", vdso_setup);
+
+
+int arch_setup_additional_pages(struct linux_binprm *bprm, int exec_stack)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned long vdso_pages;
+ unsigned long vdso_base;
+ int rv;
+
+ if (!vdso_enabled)
+ return 0;
+
+ down_write(&mm->mmap_sem);
+
+ rv = get_unmapped_area(NULL, vdso_base, vdso_pages << PAGE_SHIFT, 0, 0);
+ if (IS_ERR_VALUE(rv))
+ goto out;
+ vdso_base = rv;
+
+ rv = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+ VM_READ|VM_EXEC|
+ VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC|
+ VM_ALWAYSDUMP,
+ vdso_pagelist);
+ if (rv)
+ goto out;
+out:
+ up_write(&mm->mmap_sem);
+ return rv;
+}
+
+static int __init vdso_init(void)
+{
+ return 0;
+}
+arch_initcall(vdso_init);
diff --git a/arch/mips/kernel/vdso32/.gitignore b/arch/mips/kernel/vdso32/.gitignore
new file mode 100644
index 0000000..e45fba9
--- /dev/null
+++ b/arch/mips/kernel/vdso32/.gitignore
@@ -0,0 +1 @@
+vdso32.lds
diff --git a/arch/mips/kernel/vdso32/Makefile b/arch/mips/kernel/vdso32/Makefile
new file mode 100644
index 0000000..b1ea645
--- /dev/null
+++ b/arch/mips/kernel/vdso32/Makefile
@@ -0,0 +1,35 @@
+# List of files in the vdso
+obj-vdso32 = sigtramp.o
+
+# Build rules
+targets := $(obj-vdso32) vdso32.so
+obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32))
+
+
+EXTRA_CFLAGS := -shared -s -fno-common -fno-builtin
+EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso32.so.1
+EXTRA_CFLAGS += $(call ld-option, -Wl$(comma)--hash-style=sysv)
+
+EXTRA_AFLAGS := -D__VDSO32__ -s
+
+obj-y += vdso32.o
+extra-y += vdso32.lds
+CPPFLAGS_vdso32.lds += -P -C -U$(ARCH)
+
+# kbuild does not track this dependency due to usage of .incbin
+$(obj)/vdso32.o : $(obj)/vdso32.so
+
+# link rule for the .so file, .lds has to be first
+$(obj)/vdso32.so: $(src)/vdso32.lds $(obj-vdso32)
+ $(call if_changed,vdso32ld)
+
+# assembly rules for the .S files
+$(obj-vdso32): %.o: %.S
+ $(call if_changed_dep,vdso32as)
+
+# actual build commands
+quiet_cmd_vdso32ld = VDSO32_LD $@
+ cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@
+quiet_cmd_vdso32as = VDSO32_AS $@
+ cmd_vdso32as = $(CC) $(a_flags) -c -o $@ $<
+
diff --git a/arch/mips/kernel/vdso32/sigtramp.S b/arch/mips/kernel/vdso32/sigtramp.S
new file mode 100644
index 0000000..4f83203
--- /dev/null
+++ b/arch/mips/kernel/vdso32/sigtramp.S
@@ -0,0 +1,13 @@
+#include <asm/asm.h>
+#include <asm/regdef.h>
+#include <asm/unistd.h>
+
+LEAF(__kernel_sigtramp_32)
+ li v0, __NR_sigreturn
+ syscall
+END(__kernel_sigtramp_32)
+
+LEAF(__kernel_sigtramp_rt32)
+ li v0, __NR_rt_sigreturn
+ syscall
+END(__kernel_sigtramp_rt32)
diff --git a/arch/mips/kernel/vdso32/vdso32.S b/arch/mips/kernel/vdso32/vdso32.S
new file mode 100644
index 0000000..9548930
--- /dev/null
+++ b/arch/mips/kernel/vdso32/vdso32.S
@@ -0,0 +1,11 @@
+#include <linux/init.h>
+
+__INITDATA
+
+ .globl vdso32_start
+ .globl vdso32_end
+vdso32_start:
+ .incbin "arch/mips/kernel/vdso32/vdso32.so"
+vdso32_end:
+
+__FINIT
diff --git a/arch/mips/kernel/vdso32/vdso32.lds.S b/arch/mips/kernel/vdso32/vdso32.lds.S
new file mode 100644
index 0000000..250a03d
--- /dev/null
+++ b/arch/mips/kernel/vdso32/vdso32.lds.S
@@ -0,0 +1,73 @@
+/*
+ * Linker script for vsyscall DSO. The vsyscall page is an ELF shared
+ * object prelinked to its virtual address, and with only one read-only
+ * segment (that fits in one page). This script controls its layout.
+ */
+#include <asm/asm-offsets.h>
+
+/* Default link addresses for the vDSOs */
+#define VDSO32_LBASE 0x100000
+#define VDSO64_LBASE 0x100000
+
+/* Default map addresses */
+#define VDSO32_MBASE VDSO32_LBASE
+#define VDSO64_MBASE VDSO64_LBASE
+
+OUTPUT_ARCH(mips)
+ENTRY(__kernel_sigtramp_32);
+
+SECTIONS
+{
+ . = VDSO32_LBASE + SIZEOF_HEADERS;
+
+ .hash : { *(.hash) } :text
+ .gnu.hash : { *(.gnu.hash) }
+ .dynsym : { *(.dynsym) }
+ .dynstr : { *(.dynstr) }
+ .gnu.version : { *(.gnu.version) }
+ .gnu.version_d : { *(.gnu.version_d) }
+ .gnu.version_r : { *(.gnu.version_r) }
+
+ . = ALIGN(16);
+
+ .text : { *(.text) } :text
+ .note : { *(.note.*) } :text :note
+ .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr
+ .eh_frame : { KEEP (*(.eh_frame)) } :text
+
+ .dynamic : { *(.dynamic) } :text :dynamic
+ .got : { *(.got) }
+ .plt : { *(.plt) }
+
+ /DISCARD/ : {
+ *(.got.plt) *(.got)
+ *(.data .data.* .gnu.linkonce.d.*)
+ *(.dynbss)
+ *(.bss .bss.* .gnu.linkonce.b.*)
+ } :text
+}
+
+/*
+ * We must supply the ELF program headers explicitly to get just one
+ * PT_LOAD segment, and set the flags explicitly to make segments read-only.
+ */
+PHDRS
+{
+ text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */
+ dynamic PT_DYNAMIC FLAGS(4); /* PF_R */
+ note PT_NOTE FLAGS(4); /* PF_R */
+ eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */
+}
+
+/*
+ * This controls what symbols we export from the DSO.
+ */
+VERSION
+{
+ LINUX_2.6.24 {
+ global:
+ __kernel_sigtramp_32;
+ __kernel_sigtramp_rt32;
+ local: *;
+ };
+}
^ permalink raw reply related
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: David Daney @ 2007-11-13 16:12 UTC (permalink / raw)
To: linux-mips; +Cc: Richard Sandiford, gcc
In-Reply-To: <473957B6.3030202@avtrex.com>
David Daney wrote:
> With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> impossible for GCC's exception unwinding machinery to unwind through
> signal frames. The cause of the problems is the
> ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> impossible to determine offset from the signal return trampoline. The
> unwinder depends on being able to find the sigcontext given a known
> location of the trampoline.
>
> It seems there are a couple of possible solutions:
>
> 1) The comments in war.h indicate the problem only exists in R7000 and
> E9000 processors. We could turn off the workaround if the kernel is
> configured for R5000. That would help me, but not those with the
> effected systems.
>
> 2) In the non-workaround case, the siginfo immediately follows the
> trampoline and the first member is the signal number. For the
> workaround case the first word following the trampoline is zero. We
> could replace this with the offset to the sigcontext which is always a
> small negative value. The unwinder could then distinguish the two
> cases (signal numbers are positive and the offset negative). If we
> did this, the change would have to be coordinated with GCC's unwinder
> (in libgcc_s.so.1).
>
I think I have found a solution that doesn't require kernel changes.
The CFA (i.e. the stack pointer of the signal handler) of the the
context when calling mips_fallback_frame_state is at a constant offset
from the sigcontext. I can just use the CFA instead of the trampoline's
address.
Does this seem plausible?
Thanks,
David Daney
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Ralf Baechle @ 2007-11-13 15:08 UTC (permalink / raw)
To: Kevin D. Kissell
Cc: Franck Bui-Huu, Andrew Haley, David Daney, linux-mips,
Richard Sandiford, gcc
In-Reply-To: <019e01c82602$f5463bf0$10eca8c0@grendel>
On Tue, Nov 13, 2007 at 03:37:39PM +0100, Kevin D. Kissell wrote:
> True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> systems (which I know you work on) where it's even possible for the stack
> *not* to have exec permissions, since the classical MIPS MMU gives
> execute permission to any page that is readable.
Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take
care of I-cache coherency. So it's somewhat beneficial even in absence of
a protection bit in the actual TLB hardware.
Some of these performance optimizations are impossible because the kernel
can't have definate knowledge that certain addresses have never entered the
I-cache.
Ralf
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Ralf Baechle @ 2007-11-13 15:01 UTC (permalink / raw)
To: Franck Bui-Huu
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <cda58cb80711130622u7ef77870iae407f7c8054e9da@mail.gmail.com>
On Tue, Nov 13, 2007 at 03:22:33PM +0100, Franck Bui-Huu wrote:
> > > And the stack wouldn't need to have exec permission anymore.
> >
> > Oh?
> >
> > extern void frob(void (*)(void));
> >
> > int foo(void)
> > {
> > int x;
> >
> > void bar(void)
> > {
> > x++;
> > }
> >
> > frob(&bar);
> > print("x is %d\n", x);
> > }
> >
> > Compile and enjoy.
> >
>
> Sorry Ralf, I missed your point.
This piece of code compiles to something that copies a trampoline to the
stack. The address of that trampoline is what is then passed as argument
to frob().
Old versions of glibc were probable the most notorious users of trampolines.
Objective C also generates them. Since a cacheflush that is a syscall is
required performance is less than great.
Which means the libc() cacheflush() function is another candidate for a
vDSO, it can be optimized by using SYNCI on some configurations.
Ralf
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Franck Bui-Huu @ 2007-11-13 14:49 UTC (permalink / raw)
To: Kevin D. Kissell
Cc: Ralf Baechle, Andrew Haley, David Daney, linux-mips,
Richard Sandiford, gcc
In-Reply-To: <019e01c82602$f5463bf0$10eca8c0@grendel>
On Nov 13, 2007 3:37 PM, Kevin D. Kissell <kevink@mips.com> wrote:
> Franck a dit:
> > > Another reason is to get rid of the classic trampoline the kernel installs
> > > on the stack. On some multiprocessor systems it requires a cacheflush
> > > operation to be performed on all processors which is expensive. Having
> > > the trampoline in a vDSO would solve that.
> > >
> >
> > And the stack wouldn't need to have exec permission anymore.
>
> True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> systems (which I know you work on) where it's even possible for the stack
> *not* to have exec permissions, since the classical MIPS MMU gives
> execute permission to any page that is readable.
>
Well, the noexec stack is pretty usefull I think. I can't believe it
will be limited to these 2 systems in the near future...
--
Franck
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Kevin D. Kissell @ 2007-11-13 14:37 UTC (permalink / raw)
To: Franck Bui-Huu, Ralf Baechle
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <cda58cb80711130514x16356ea3x4069616c9ee3caac@mail.gmail.com>
Franck a dit:
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
> > operation to be performed on all processors which is expensive. Having
> > the trampoline in a vDSO would solve that.
> >
>
> And the stack wouldn't need to have exec permission anymore.
True, though it should perhaps be noted that currently it's only on 4KSc/Sd
systems (which I know you work on) where it's even possible for the stack
*not* to have exec permissions, since the classical MIPS MMU gives
execute permission to any page that is readable.
Regards,
Kevin K.
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Kevin D. Kissell @ 2007-11-13 14:37 UTC (permalink / raw)
To: Franck Bui-Huu, Ralf Baechle
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <cda58cb80711130514x16356ea3x4069616c9ee3caac@mail.gmail.com>
Franck a dit:
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
> > operation to be performed on all processors which is expensive. Having
> > the trampoline in a vDSO would solve that.
> >
>
> And the stack wouldn't need to have exec permission anymore.
True, though it should perhaps be noted that currently it's only on 4KSc/Sd
systems (which I know you work on) where it's even possible for the stack
*not* to have exec permissions, since the classical MIPS MMU gives
execute permission to any page that is readable.
Regards,
Kevin K.
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Franck Bui-Huu @ 2007-11-13 14:22 UTC (permalink / raw)
To: Ralf Baechle
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <20071113140036.GA7650@linux-mips.org>
On Nov 13, 2007 3:00 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
>
> On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
>
> > > > David Daney writes:
> > > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > > signal frames. The cause of the problems is the
> > > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > > > > impossible to determine offset from the signal return trampoline. The
> > > > > unwinder depends on being able to find the sigcontext given a known
> > > > > location of the trampoline.
> > > > >
> > > > > It seems there are a couple of possible solutions:
> > > > >
> > > > > 1) The comments in war.h indicate the problem only exists in R7000
> > > > > and E9000 processors. We could turn off the workaround if the
> > > > > kernel is configured for R5000. That would help me, but not those
> > > > > with the effected systems.
> > > > >
> > > > > 2) In the non-workaround case, the siginfo immediately follows the
> > > > > trampoline and the first member is the signal number. For the
> > > > > workaround case the first word following the trampoline is zero.
> > > > > We could replace this with the offset to the sigcontext which is
> > > > > always a small negative value. The unwinder could then distinguish
> > > > > the two cases (signal numbers are positive and the offset
> > > > > negative). If we did this, the change would have to be coordinated
> > > > > with GCC's unwinder (in libgcc_s.so.1).
> > > > >
> > > > > Thoughts?
> > > >
> > > > The best solution is to put the unwinder info in the kernel. Does
> > > > MIPS use a vDSO ?
> > >
> > > No though we should.
> > >
> > > Another reason is to get rid of the classic trampoline the kernel installs
> > > on the stack. On some multiprocessor systems it requires a cacheflush
> > > operation to be performed on all processors which is expensive. Having
> > > the trampoline in a vDSO would solve that.
> > >
> >
> > And the stack wouldn't need to have exec permission anymore.
>
> Oh?
>
> extern void frob(void (*)(void));
>
> int foo(void)
> {
> int x;
>
> void bar(void)
> {
> x++;
> }
>
> frob(&bar);
> print("x is %d\n", x);
> }
>
> Compile and enjoy.
>
Sorry Ralf, I missed your point.
--
Franck
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Ralf Baechle @ 2007-11-13 14:00 UTC (permalink / raw)
To: Franck Bui-Huu
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <cda58cb80711130514x16356ea3x4069616c9ee3caac@mail.gmail.com>
On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
> > > David Daney writes:
> > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > signal frames. The cause of the problems is the
> > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > > > impossible to determine offset from the signal return trampoline. The
> > > > unwinder depends on being able to find the sigcontext given a known
> > > > location of the trampoline.
> > > >
> > > > It seems there are a couple of possible solutions:
> > > >
> > > > 1) The comments in war.h indicate the problem only exists in R7000
> > > > and E9000 processors. We could turn off the workaround if the
> > > > kernel is configured for R5000. That would help me, but not those
> > > > with the effected systems.
> > > >
> > > > 2) In the non-workaround case, the siginfo immediately follows the
> > > > trampoline and the first member is the signal number. For the
> > > > workaround case the first word following the trampoline is zero.
> > > > We could replace this with the offset to the sigcontext which is
> > > > always a small negative value. The unwinder could then distinguish
> > > > the two cases (signal numbers are positive and the offset
> > > > negative). If we did this, the change would have to be coordinated
> > > > with GCC's unwinder (in libgcc_s.so.1).
> > > >
> > > > Thoughts?
> > >
> > > The best solution is to put the unwinder info in the kernel. Does
> > > MIPS use a vDSO ?
> >
> > No though we should.
> >
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
> > operation to be performed on all processors which is expensive. Having
> > the trampoline in a vDSO would solve that.
> >
>
> And the stack wouldn't need to have exec permission anymore.
Oh?
extern void frob(void (*)(void));
int foo(void)
{
int x;
void bar(void)
{
x++;
}
frob(&bar);
print("x is %d\n", x);
}
Compile and enjoy.
Ralf
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Franck Bui-Huu @ 2007-11-13 13:14 UTC (permalink / raw)
To: Ralf Baechle
Cc: Andrew Haley, David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <20071113121036.GA6582@linux-mips.org>
On Nov 13, 2007 1:10 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
>
> On Tue, Nov 13, 2007 at 11:48:53AM +0000, Andrew Haley wrote:
>
> > David Daney writes:
> > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > impossible for GCC's exception unwinding machinery to unwind through
> > > signal frames. The cause of the problems is the
> > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > > impossible to determine offset from the signal return trampoline. The
> > > unwinder depends on being able to find the sigcontext given a known
> > > location of the trampoline.
> > >
> > > It seems there are a couple of possible solutions:
> > >
> > > 1) The comments in war.h indicate the problem only exists in R7000
> > > and E9000 processors. We could turn off the workaround if the
> > > kernel is configured for R5000. That would help me, but not those
> > > with the effected systems.
> > >
> > > 2) In the non-workaround case, the siginfo immediately follows the
> > > trampoline and the first member is the signal number. For the
> > > workaround case the first word following the trampoline is zero.
> > > We could replace this with the offset to the sigcontext which is
> > > always a small negative value. The unwinder could then distinguish
> > > the two cases (signal numbers are positive and the offset
> > > negative). If we did this, the change would have to be coordinated
> > > with GCC's unwinder (in libgcc_s.so.1).
> > >
> > > Thoughts?
> >
> > The best solution is to put the unwinder info in the kernel. Does
> > MIPS use a vDSO ?
>
> No though we should.
>
> Another reason is to get rid of the classic trampoline the kernel installs
> on the stack. On some multiprocessor systems it requires a cacheflush
> operation to be performed on all processors which is expensive. Having
> the trampoline in a vDSO would solve that.
>
And the stack wouldn't need to have exec permission anymore.
> I need to look into it, not sure what it would take.
>
I started to add vdso support for MIPS a couple months ago, but
it's in a very early stage and I unfortunately haven't time to finish
it. I can send it to you if you want.
--
Franck
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Ralf Baechle @ 2007-11-13 12:10 UTC (permalink / raw)
To: Andrew Haley; +Cc: David Daney, linux-mips, Richard Sandiford, gcc
In-Reply-To: <18233.36645.232058.964652@zebedee.pink>
On Tue, Nov 13, 2007 at 11:48:53AM +0000, Andrew Haley wrote:
> David Daney writes:
> > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > impossible for GCC's exception unwinding machinery to unwind through
> > signal frames. The cause of the problems is the
> > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> > impossible to determine offset from the signal return trampoline. The
> > unwinder depends on being able to find the sigcontext given a known
> > location of the trampoline.
> >
> > It seems there are a couple of possible solutions:
> >
> > 1) The comments in war.h indicate the problem only exists in R7000
> > and E9000 processors. We could turn off the workaround if the
> > kernel is configured for R5000. That would help me, but not those
> > with the effected systems.
> >
> > 2) In the non-workaround case, the siginfo immediately follows the
> > trampoline and the first member is the signal number. For the
> > workaround case the first word following the trampoline is zero.
> > We could replace this with the offset to the sigcontext which is
> > always a small negative value. The unwinder could then distinguish
> > the two cases (signal numbers are positive and the offset
> > negative). If we did this, the change would have to be coordinated
> > with GCC's unwinder (in libgcc_s.so.1).
> >
> > Thoughts?
>
> The best solution is to put the unwinder info in the kernel. Does
> MIPS use a vDSO ?
No though we should.
Another reason is to get rid of the classic trampoline the kernel installs
on the stack. On some multiprocessor systems it requires a cacheflush
operation to be performed on all processors which is expensive. Having
the trampoline in a vDSO would solve that.
I need to look into it, not sure what it would take.
Ralf
^ permalink raw reply
* Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0
From: Maciej W. Rozycki @ 2007-11-13 12:10 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20071112223104.GA7900@alpha.franken.de>
On Mon, 12 Nov 2007, Thomas Bogendoerfer wrote:
> I simply used call_o32.S from the decstation part and missed the
> fact, that it simply uses the normal kernel stack when calling
> firmware. This works quite good until the first kernel thread
> gets scheduled, which has a kernel stack via a CAC_BASE address.
You could do stack switching in call_o32() -- I just figured there was no
point in adding this complication as the DECstation always runs from KSEG0
-- it has the maximum of 480MB of RAM mapped linearly starting from 0.
Maciej
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Andrew Haley @ 2007-11-13 11:48 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips, Richard Sandiford, gcc
In-Reply-To: <473957B6.3030202@avtrex.com>
David Daney writes:
> With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> impossible for GCC's exception unwinding machinery to unwind through
> signal frames. The cause of the problems is the
> ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost
> impossible to determine offset from the signal return trampoline. The
> unwinder depends on being able to find the sigcontext given a known
> location of the trampoline.
>
> It seems there are a couple of possible solutions:
>
> 1) The comments in war.h indicate the problem only exists in R7000
> and E9000 processors. We could turn off the workaround if the
> kernel is configured for R5000. That would help me, but not those
> with the effected systems.
>
> 2) In the non-workaround case, the siginfo immediately follows the
> trampoline and the first member is the signal number. For the
> workaround case the first word following the trampoline is zero.
> We could replace this with the offset to the sigcontext which is
> always a small negative value. The unwinder could then distinguish
> the two cases (signal numbers are positive and the offset
> negative). If we did this, the change would have to be coordinated
> with GCC's unwinder (in libgcc_s.so.1).
>
> Thoughts?
The best solution is to put the unwinder info in the kernel. Does
MIPS use a vDSO ?
Andrew.
^ permalink raw reply
* Re: [SPAM] Re: Donation of an Indigo 2 R4K@250
From: Martin Michlmayr @ 2007-11-13 8:21 UTC (permalink / raw)
To: Markus Gothe; +Cc: linux-mips
In-Reply-To: <47385B75.2010700@27m.se>
* Markus Gothe <markus.gothe@27m.se> [2007-11-12 14:56]:
> Which graphics option? A 'hinv -v' would be appreciated.
I've asked the donor.
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox