svn commit: r225892 - head/sys/mips/mips

[Andrew Duane]

The COP0_SYNC's should be there (should there also be one after the MTC0 in MipsKernIntr?). The ISA says a hazard is needed, so that should be reflected. I assume different platforms define COP0_SYNC for themselves as needed?

Other comment: rather than adding 16 to the StartSkipWait address if skipping over it, should the address of EndSkipWait be loaded instead? I can see some real problems someday when the skip stuff goes past 16 bytes.

 ...................................
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
aduane at juniper.net

 


> -----Original Message-----
> From: owner-freebsd-mips at freebsd.org [mailto:owner-freebsd-
> mips at freebsd.org] On Behalf Of Jayachandran C.
> Sent: Monday, October 03, 2011 2:53 PM
> To: Adrian Chadd
> Cc: Kostik Belousov; Alexander Motin; freebsd-mips at freebsd.org
> Subject: Re: svn commit: r225892 - head/sys/mips/mips
> 
> On Tue, Oct 4, 2011 at 12:34 AM, Jayachandran C. <jchandra at freebsd.org>
> wrote:
> > On Mon, Oct 3, 2011 at 10:19 PM, Jayachandran C.
> <jchandra at freebsd.org> wrote:
> >> Hi Adrain,
> >>
> >> On Sun, Oct 2, 2011 at 4:33 PM, Kostik Belousov
> <kostikbel at gmail.com> wrote:
> >>> On Sun, Oct 02, 2011 at 05:28:25PM +0800, Adrian Chadd wrote:
> >>>> Hi,
> >>>>
> >>>> It doesn't look like openbsd or netbsd have tried addressing this.
> >>>>
> >>>> I took a shot at trying to port over the relevant bits.
> >>>>
> >>>> Linux seems to store the "can reschedule" flag in a bit of memory,
> >>>> rather than calling a function to check each time.
> >>>> This means that I can't simply port r4k_wait() verbose; there's no
> >>>> guarantee EPC would be pointing to inside r4k_wait if it had to
> >>>> call sched_runnable().
> >>>>
> >>>> Also, since we are calling 'wait' inside a critical section, any
> >>>> EPC unwinding would have to also unwind the critical section (and
> >>>> maybe reprogram the timer) before restarting things. But since
> that
> >>>> now makes the "rollback" section even larger and unwieldy.
> >>>>
> >>>> I really don't have the time or brain power at the moment to try
> >>>> and port this solution over from Linux.
> >>>>
> >>>> I would really appreciate it if someone would help out here.
> >>>
> >>> I probably need to describe some details of the mentioned "kib'
> idea".
> >>>
> >>> Looking at the x86 sti; hlt sequence, I noted that, in fact, we do
> >>> not strictly need the special CPU behaviour of delaying enabling
> the
> >>> interrupts till next instruction after sti is executed. The race
> >>> there is the interrupt happen right after sti but before hlt,
> >>> causing CPU to enter halted state while potentially having runnable
> >>> thread. On x86 it is closed by sti not enabling interrupts till hlt
> >>> started execution (it is more subtle, but let ignore the detail for
> the discussion).
> >>>
> >>> Now, if sti would not offer the useful postponing behaviour, we can
> >>> easily emulate it. In the hardware interrupt handlers return path,
> >>> we can check for $pc being equal to the address of the hlt
> >>> instruction. If it is, we can advance $pc over the hlt, avoiding
> the
> >>> halt if potentially we have a runnable thread.
> >>>
> >>> Briefly looking over the MIPS64 specifications, I do not see why we
> >>> cannot implement the spirit of the trick for the ei; wait
> instruction sequence.
> >>> ray talked about possibility of $pc living in the shadow register
> >>> bank, which I think is not important. Another (minor) issue seems
> to
> >>> be that our code does not use ei, directly manipulating the bit.
> >>>
> >>> My belief is that the trick can be done if only we have exact
> >>> interrupts. It seems, from "run mips run" text, that possible
> >>> inexact interrupts are either for much older platforms then modern
> >>> MIPS SoC, or are irrelant there, because inexactness is only
> related to mul/div unit.
> >>>
> >>> [I am not on mips@]
> >>
> >> I have implemented a variant of this, can you try out the attached
> >> patch and see how it goes? It should apply on the version before
> your
> >> changes to machdep.c
> >>
> >> Also, if anybody on mips@ can review the code, it would be
> helpful...
> >
> > Actually there are two issues with this, the first is a simple bug,
> it
> > should be :
> > mtc0    t1, MIPS_COP_0_STATUS
> >
> > The second one is that a move to the status register should followed
> > by a COP0 write hazard on some mips platforms (although not on
> > XLR/XLP). Adding this hazard would make the calculations more
> > complex....
> 
> This version should be better(thanks to Juli for suggestions).  Can you
> see if this helps?
> 
> Thanks,
> JC