Date: Wed, 30 Jul 2003 20:47:49 -0400 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/lib/libthr/arch/alpha/alpha _curthread.c Message-ID: <20030730204749.A75933@grasshopper.cs.duke.edu> In-Reply-To: <20030724232117.GA1913@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Thu, Jul 24, 2003 at 04:21:17PM -0700 References: <20030724191943.GA1028@dhcp01.pn.xcllnt.net> <XFMail.20030724170013.jhb@FreeBSD.org> <20030724232117.GA1913@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar [marcel@xcllnt.net] wrote: > On Thu, Jul 24, 2003 at 05:00:13PM -0400, John Baldwin wrote: > > > > There is a chicken and egg problem. We use the unique value to > > initialize the per-cpu pointer on kernel entry. We only have one > > such beast, and in the kernel we cache it in a register that userland > > gets to clobber (and frequently does). If you can think of a better > > way to store the per-cpu pointer such that kernel entry can load it > > into the register go for it. > > I see where the confusion is: > > > pcpup = (struct pcpu *) alpha_pal_rdval(); > ^^^^^^^^^^^^^^^^^^^^^^ > > This is not the per-CPU unique value. I had to add alpha_pal_rdunique() > in order to access it. In numbers: > > PAL_rdval = PAL_OSF1_rdval = 0x0032 > PAL_rdunique = 0x009e > > PAL_rdval is a privileged operation PAL_rdunique isn't. > > There is no fundamental problem (although my alpha does reboot > when I run a 1:1-threaded application, so there is a problem :-) > FWIW, if we need another way to get to pcpu, we can always use alpha_pal_whami() to index into an array of pre-allocated per-cpu structs. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030730204749.A75933>