Date: Tue, 07 May 1996 04:49:54 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: smp@freebsd.org Subject: Re: CVS update: sys/i386/i386 Message-ID: <199605062049.EAA04998@spinner.DIALix.COM> In-Reply-To: Your message of "Mon, 06 May 1996 20:18:28 GMT." <10204.831413908@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> - the APIC is no longer mapped Virtual == Physical, because this required >> tweaking of the PTD's and other nightmares. It now is dereferenced >> via a pointer (unsigned int *apic_base;) >should be (unsigned int *lapic_base) ? That's the least of our worries at the moment.. ;-) ;-) >> - the APIC register defines redone to cope with this. Now are offsets >> instead of absolute addresses. This means that the boot code needs to >> manually compensate when it's making a physical reference before paging >> is set up. It also means that _get_mplock cannot be used before paging >> is enabled. >get_mplock isn't called until after paging is enabled, no worries. I was pretty sure this was the case, I didn't see any escapes from locore.s beforehand, and I'm not aware of any cases where paging is disabled after booting.. :-) >> - pmap.c sets up the apic mapping in rather than locore. A lot of the othe >r >> apic initialisation could be done in C too rather than mpcore.s/locore.s >yes, yes, YES! Also: One stack/PTD/PCB/UPAGES can be created later in the boot after the memory allocator is running so that one idle pcb (for the recursive mplock nesting count) and stack is available per 'n' cpus, rather than forking an entire process and keeping them running outside of the idle loop. Hmm, machdep.c can call something to parse the MP config block to see how many cpus it can expect to find. No wait.. We have an option for this, NCPU.. :-) I'm tired.. It's 5AM again.. :-( >-- >Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. >http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. >whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc >. >Future will arrive by its own means, progress not so. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605062049.EAA04998>