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