Date: Mon, 03 Sep 2001 03:58:38 -0700 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: ia64@FreeBSD.ORG, jhb@FreeBSD.ORG, dfr@FreeBSD.ORG Subject: Re: ia64 + kse == not^H^H^Hnow happy.. Message-ID: <20010903105838.EF3FF380C@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.33.0109031127410.30587-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote:
> On Mon, 3 Sep 2001, Peter Wemm wrote:
>
> > I finally solved it. I did a s/proc0/thread0/ in locore.s, forgetting that
> > proc0 is a structure, and thread0 is a pointer that requires indirection.
> >
> > Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()?
>
> Each register has an associated bit which determines whether it contains a
> valid value. These "not a thing" bits are accumulated into the ar.rnat
> register as registers are written to the register stack. After stacking 63
> registers, the accumulated NaT bits are written to the stack. This happens
> when the ar.bspstore pointer rolls past xxxxx1f8. To correctly fork a
> child process, we must initialise its register stack and ar.rnat value so
> that it contains reasonable values when its resumed. The correct ar.rnat
> value is either the current process' ar.rnat if it has not yet been
> flushed out since we entered the kernel or the value stored at rnatloc
> otherwise. We determine this by checking to see if the current process'
> ar.bspstore has gone past rnatloc.
Aha! that make some sense. I'm starting to understand the ia64 manuals
now too.
Question.. |= 1f8 depends on the stack starting at a xxxx000 address, right?
The original committed ia64+kse stuff that worked had the pcb
at the base of the stack, which meant that the bspstore started at some
address like xxxx680. That |= 1f8 isn't space for a full 63 registers.
Is it the address that is magic or the offset? Should it have been
+= 1f8 instead of |= ?
In any case it shouldn't matter now since the bspstore starts at a xxx000
address now in the kse kernel (the pcb is at the top-of-stack, above
trapframe and sp.)
Speaking of sp, I've left some XXX comments about the -16 and +16 stuff...
What is going on there?
td2->td_pcb->pcb_sp = (u_int64_t)p2tf - 16;
Is that just to arrange stack alignment on 16 byte boundaries? ie: like
how we subtract sizeof(void *) in the i386 case but instead of 4 bytes
it is 16?
> > Some things I have noticed are missing:
> > setjmp/longjmp() (these look non-trivial given the register stack :-( )
> > lots and lots and lots of minor things. :-)
>
> I started working on this as part of an effort to get ficl working in the
> EFI based loader. I got a bit stuck though - I probably should set up a
> testcase that I can run under ski.
Out of curiosity, what kind of lengths will setjmp/longjmp need to go
to? I'm suprised ddb hasn't exploded because of this..
If I had to guess, I would expect it to look a bit like the code in the
tail end of cpu_fork().. ie: copy base registers, turn off rse, flush
to backing store, turn rse back on?
> > I have been considering taking a shot at porting loader(8) to run under
> > ski, and have *it* load the kernel via reading via sscdisk style
> > operations.. This should enable us to have better control of our
> > boot environment, symbol tables, etc. I think. :-]
>
> Ooh. I want one.
Heh. dont we all. :-)
Seriously, I think loader-under-ski is a good intermediate step before
loader-under-efi, unless the efi case is already close to working. Even
without ficl would be useful since we could have a real boot environment.
Now to get the magic wand over to David O'Brien to get the gcc3 stuff with
basic ia64 support in it. :-)
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010903105838.EF3FF380C>