Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Nov 2008 12:49:19 -0600
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 153267 for review
Message-ID:  <4925B12F.5040909@freebsd.org>
In-Reply-To: <1DD739B8-6D48-49DC-8BAC-299D9AD9FC4C@mac.com>
References:  <200811201707.mAKH7dcT045326@repoman.freebsd.org> <1DD739B8-6D48-49DC-8BAC-299D9AD9FC4C@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote:
>
> On Nov 20, 2008, at 9:07 AM, Nathan Whitehorn wrote:
>
>> http://perforce.freebsd.org/chv.cgi?CH=153267
>>
>> Change 153267 by nwhitehorn@nwhitehorn_trantor on 2008/11/20 17:07:25
>>
>>     Make ofw_real work on kernels with options SMP by making the bounce
>>     page static. On SMP systems, we can get OF calls after the MMU is on
>>     but before the VM is up. This means contigmalloc() is not available.
>>     This is not a good solution, but I can't think of anything else.
>
> You can grab pages by adjusting phys_avail. This achieves
> pretty much the same, but avoids bloating the kernel. If
> it's possible to give those pages back to the VM after the
> VM has been initialized, then that would be another
> benefit...
The trouble with doing things like this is that the OF access code can 
be called at unpredictable times, so it may not be called between the 
time the MMU turns on (and phys_avail is created), and when the VM has 
taken ownership of phys_avail. It then needs knowledge of how far along 
it is in the boot process in much more detail than !pmap_bootstrapped in 
order to determine exactly what it is allowed to do at that time. An 
alternative is that the MMU init code could allocate the page, but it 
then needs to know about the internals of the OF access, which I would 
like to avoid.

I suppose we could checkpoint this with some sysinits bracketed around 
the VM system, but that starts getting ugly. It might be the only way to 
proceed that doesn't bloat the kernel, though.
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4925B12F.5040909>