On Tue, Oct 07, 2014 at 04:59:03PM -0700, David Daney wrote:
> On 10/07/2014 04:20 PM, Ralf Baechle wrote:
> >On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >
> >>>As an alternative, if the space of possible instruction with a delay
> >>>slot is sufficiently small, all such instruct
On Tue, Oct 07, 2014 at 07:18:33PM -0500, Chuck Ebbert wrote:
> On Tue, 7 Oct 2014 16:59:03 -0700
> David Daney wrote:
>
> > On 10/07/2014 04:20 PM, Ralf Baechle wrote:
> > > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> > >
> > >>> As an alternative, if the space of possible ins
On Oct 7, 2014 1:03 PM, "David Daney" wrote:
>
> On 10/07/2014 12:28 PM, Andy Lutomirski wrote:
>>
>> On Tue, Oct 7, 2014 at 12:21 PM, Rich Felker wrote:
>>>
>>> On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
On 10/07/2014 12:09 PM, Rich Felker wrote:
>
> I agr
On Tue, 7 Oct 2014 16:59:03 -0700
David Daney wrote:
> On 10/07/2014 04:20 PM, Ralf Baechle wrote:
> > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >
> >>> As an alternative, if the space of possible instruction with a delay
> >>> slot is sufficiently small, all such instruction
On 10/07/2014 04:20 PM, Ralf Baechle wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
As an alternative, if the space of possible instruction with a delay
slot is sufficiently small, all such instructions could be mapped as
immutable code in a shared mapping, each at a fixed
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >As an alternative, if the space of possible instruction with a delay
> >slot is sufficiently small, all such instructions could be mapped as
> >immutable code in a shared mapping, each at a fixed offset in the
> >mapping. I suspect th
On 10/07/2014 12:28 PM, Andy Lutomirski wrote:
On Tue, Oct 7, 2014 at 12:21 PM, Rich Felker wrote:
On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
On 10/07/2014 12:09 PM, Rich Felker wrote:
I agree completely here. We should not break things (or, as it
seems, leave them broke
> >
> > 4) The voice for doing any instruction emulation in kernel - it is not a
> > MIPS business model to force customer to put details of all Coprocessor 2
> > instructions public. We provide an interface and the rest is a customer
> > business. Besides that it is really painful to make a diffe
On Tue, Oct 7, 2014 at 12:21 PM, Rich Felker wrote:
> On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
>> On 10/07/2014 12:09 PM, Rich Felker wrote:
>> >I agree completely here. We should not break things (or, as it
>> >seems, leave them broken) for common usage cases that affect
>
On 10/07/2014 12:21 PM, Rich Felker wrote:
The in-stack trampoline support could be left but used only for
emulating instructions the kernel doesn't know. This would make all
normal binaries immediately usable with non-executable stack, and
would avoid the only potential source of regressions.
On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
> On 10/07/2014 12:09 PM, Rich Felker wrote:
> >I agree completely here. We should not break things (or, as it
> >seems, leave them broken) for common usage cases that affect
> >everyone just to coddle proprietary vendor-specific inst
On 10/07/2014 12:09 PM, Rich Felker wrote:
I agree completely here. We should not break things (or, as it seems,
leave them broken) for common usage cases that affect everyone just to
coddle proprietary vendor-specific instructions. The latter just
should not be used in delay slots unless the c
(repeat it because of some e-mail failure, sorry)
On 10/07/2014 11:43 AM, David Daney wrote:
Five lines per instruction.
But you must be able to emulate them, so you need an emulator, not XOL.
I feel I didn't say clear - emulation of ADDIUPC (after second look it
is the only instruction requ
On Tue, Oct 07, 2014 at 11:44:35AM -0700, Andy Lutomirski wrote:
> > 4) The voice for doing any instruction emulation in kernel - it is not a
> > MIPS business model to force customer to put details of all Coprocessor 2
> > instructions public. We provide an interface and the rest is a customer
>
On 10/07/2014 11:44 AM, Andy Lutomirski wrote:
On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin
wrote:
Well, I am not a subscriber to mail-list, so I read it the first time and
some notes:
3) The signal happened during execution of emulated instruction - signals
are under control of kerne
On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin
wrote:
> Well, I am not a subscriber to mail-list, so I read it the first time and
> some notes:
>
>
> 3) The signal happened during execution of emulated instruction - signals
> are under control of kernel and we can easily delay a signal during
On 10/07/2014 11:32 AM, Leonid Yegoshin wrote:
Well, I am not a subscriber to mail-list, so I read it the first time
and some notes:
1) David's approach would likely work for FPU emulation but unlikely
works for MIPS Rel 2/Rel 1/ MIPS I emulation in MIPS R6 architecture.
The reason is that the
Well, I am not a subscriber to mail-list, so I read it the first time
and some notes:
1) David's approach would likely work for FPU emulation but unlikely
works for MIPS Rel 2/Rel 1/ MIPS I emulation in MIPS R6 architecture.
The reason is that the first MIPS R2 instruction (removed from MIPS
On Oct 7, 2014 9:09 AM, "David Daney" wrote:
>
> On 10/07/2014 04:11 AM, Rich Felker wrote:
>>
>> On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
>
> the out-of-line execution trick, but do it somewhere other than in
> stack memory.
How do you answer Andy Lutomir
On 10/07/2014 04:11 AM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
the out-of-line execution trick, but do it somewhere other than in
stack memory.
How do you answer Andy Lutomirski's question about what happens when a
signal handler interrupts execution whi
On 10/07/2014 02:13 AM, Matthew Fortune wrote:
the out-of-line execution trick, but do it somewhere other than in
stack memory.
How do you answer Andy Lutomirski's question about what happens when a
signal handler interrupts execution while the program counter is
pointing at this "out-of-line ex
On 07/10/14 12:53, James Hogan wrote:
> On 07/10/14 05:32, David Daney wrote:
>> If the kernel automatically allocated the emulation locations, what
>> would happen if there were a signal that interrupted the emulation, and
>> the signal handler did a longjump to somewhere else? How would we clean
On 07/10/14 05:32, David Daney wrote:
> If the kernel automatically allocated the emulation locations, what
> would happen if there were a signal that interrupted the emulation, and
> the signal handler did a longjump to somewhere else? How would we clean
> up the now unused emulation memory alloc
On Tue, Oct 07, 2014 at 09:13:22AM +, Matthew Fortune wrote:
> From what I can see the out-of-line execution of delay slot instructions
> will break micromips R3 addiupc, and all MIPS32r6 and MIPS64r6 PC-relative
> instructions (inc load/store) as they will have the wrong base. Is there
> anyth
On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
> >>the out-of-line execution trick, but do it somewhere other than in
> >>stack memory.
> >How do you answer Andy Lutomirski's question about what happens when a
> >signal handler interrupts execution while the program counter is
> >poin
On 07/10/14 10:13, Matthew Fortune wrote:
the out-of-line execution trick, but do it somewhere other than in
stack memory.
>>> How do you answer Andy Lutomirski's question about what happens when a
>>> signal handler interrupts execution while the program counter is
>>> pointing at this "
> >> the out-of-line execution trick, but do it somewhere other than in
> >> stack memory.
> > How do you answer Andy Lutomirski's question about what happens when a
> > signal handler interrupts execution while the program counter is
> > pointing at this "out-of-line execution" trampoline? This se
On 10/06/2014 05:49 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
[...]
Why not? It will emit any instructions we care to make it emit. If
we want it to emit crypto instructions with patented algorithms,
then it will do that. But we would still like to
On 10/06/2014 06:02 PM, Kevin D. Kissell wrote:
On 10/06/2014 01:23 PM, David Daney wrote:
From: David Daney
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay slot instruct
On Mon, Oct 06, 2014 at 06:02:20PM -0700, Kevin D. Kissell wrote:
> On 10/06/2014 01:23 PM, David Daney wrote:
> >From: David Daney
> >
> >In order for MIPS to be able to support a non-executable stack, we
> >need to supply a method to specify a userspace area that can be used
> >for executing emu
On 10/06/2014 01:23 PM, David Daney wrote:
From: David Daney
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay slot instructions.
We add a new system call, sys_set_fpuemul_
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
> On 10/06/2014 05:05 PM, Rich Felker wrote:
> >On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> >>On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >>>On 10/06/2014 02:58 PM, Rich Felker wrote:
> On Mon, Oct 06, 2014 at
On Mon, Oct 6, 2014 at 5:33 PM, David Daney wrote:
> On 10/06/2014 05:05 PM, Rich Felker wrote:
>>
>> On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
>>>
>>> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
>
> On Mon, Oct 06,
On 10/06/2014 05:05 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
[...]
This is a huge ill-designed mes
On 10/06/2014 05:29 PM, Andy Lutomirski wrote:
On Mon, Oct 6, 2014 at 5:28 PM, Andrew Pinski wrote:
On Mon, Oct 6, 2014 at 5:21 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 0
On Mon, Oct 6, 2014 at 5:28 PM, Andrew Pinski wrote:
> On Mon, Oct 6, 2014 at 5:21 PM, Rich Felker wrote:
>> On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
>>> On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
>>> > On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
>>
On Mon, Oct 6, 2014 at 5:21 PM, Rich Felker wrote:
> On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
>> On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
>> > On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
>> >> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
>> >> >O
On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
> On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
> > On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> >> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >> >On 10/06/2014 02:58 PM, Rich Felker wrote:
> >> >>On Mon, O
On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker wrote:
> On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
>> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
>> >On 10/06/2014 02:58 PM, Rich Felker wrote:
>> >>On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
>> [...]
>> >>This is
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
> >On 10/06/2014 02:58 PM, Rich Felker wrote:
> >>On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
> [...]
> >>This is a huge ill-designed mess.
> >
> >Amen.
> >
> >Can the kern
On Mon, Oct 6, 2014 at 4:48 PM, David Daney wrote:
> On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
>>
>> On 10/06/2014 02:58 PM, Rich Felker wrote:
>>>
>>> On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
>
> [...]
>>>
>>> This is a huge ill-designed mess.
>>
>>
>> Amen.
>>
>> Can the
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
[...]
This is a huge ill-designed mess.
Amen.
Can the kernel not just emulate the instructions directly?
In theory it could, but since the
On 10/06/2014 02:58 PM, Rich Felker wrote:
> On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
>> On 10/06/2014 02:31 PM, Rich Felker wrote:
>>> On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> Userspace should play no part in this; requiring userspace to help
> mak
On Mon, Oct 06, 2014 at 03:17:03PM -0700, David Daney wrote:
> >>Furthermore the
> >>userspace code has to be very careful in its use of the $sp
> >>register, so that it doesn't store data in places that will be
> >>used/clobbered by the kernel.
> >
> >This is not "being careful". The stack pointer
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
On 10/06/2014 02:31 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomo
On 10/06/2014 02:31 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats the
purpose of fpu emulation.
That is certainly one way of loo
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
> On 10/06/2014 02:31 PM, Rich Felker wrote:
> >On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >>>Userspace should play no part in this; requiring userspace to help
> >>>make special accomodations for fpu emulation largely
On 10/06/2014 01:54 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
From: David Daney
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> >Userspace should play no part in this; requiring userspace to help
> >make special accomodations for fpu emulation largely defeats the
> >purpose of fpu emulation.
>
> That is certainly one way of looking at it. Really it is opinion,
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
> From: David Daney
>
> In order for MIPS to be able to support a non-executable stack, we
> need to supply a method to specify a userspace area that can be used
> for executing emulated branch delay slot instructions.
>
> We add a new
From: David Daney
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay slot instructions.
We add a new system call, sys_set_fpuemul_xol_area so that userspace
threads that are u
51 matches
Mail list logo
