svn commit: r221677 - in user/avg/xcpu/sys: amd64/amd64 kern sys

Andriy Gapon avg at FreeBSD.org
Tue May 10 12:11:30 UTC 2011


on 10/05/2011 04:21 Marcel Moolenaar said the following:
> 
> On May 9, 2011, at 12:05 AM, Andriy Gapon wrote:
> 
>> Author: avg
>> Date: Mon May  9 07:05:06 2011
>> New Revision: 221677
>> URL: http://svn.freebsd.org/changeset/base/221677
>>
>> Log:
>>  re-implement hard stopping of CPUs and use it enforce panic(9) context
> 
> While you're here...
> 
> I'd like to change the whole logic and turn it into a
> rendezvous. One CPU, the one panicing can proceed. But
> I'd like to add the ability from the debugger to switch
> onto a different CPU. Such makes it possible to implement
> commands that show control and status registers, perform
> function calls on specific CPUs, as well as dump on-chip
> TLB entries and cache line contents if the CPU/platform
> supports it.
> 
> Thoughts?

I think that this is implemented in (Open)Solaris and it's quite a simple
implementation.  Slave CPUs just spin in a stop loop checking for commands from a
master CPU.  This could be called a form of a rendezvous, but I'd prefer to not
mix these concepts (i.e. hardstop/kdb case with normal rendezvous mechanism).
In fact, we already have this approach implemented in the simplest, most trivial
form - currently supported commands are: (1) restart (exit the spin loop); (2)
reset system (effective only on BSP).  The commands are all broadcast at the
moment.  We could add other meaningful commands (e.g. become a new master) quite
easily IMO and make the commands targeted (i.e. add an ability to specify a subset
of CPUs that should execute a command).

-- 
Andriy Gapon


More information about the svn-src-user mailing list