Re: l4ka Digest, Vol 30, Issue 12

We have a completely modified VM implementation to Pistachio which makes
larger than 4GB physical mappings trivial to implement. It has been
added since there was no reason not to support it.

Sure, Pistachio sigma0 can map pages it can't access, it just means that
you complicate the issue of setting up and managing page attributes
(uncached, write-through etc) since sigma0 can't modify the attributes
of those pages.

--
Carl

On Thu, 2006-06-01 at 13:18 +0200, Espen Skoglund wrote:
> [Carl van Schaik]
> > Hi Frank,
> > I'm note sure about Pistachio, but the latest NICTA N-series kernels
> > API supports up to 64GB of physical on 32bit machines. The
> > implementation does not support this yet, but it should'nt be hard
> > for us to fix this.
> 
> > Pistachio is limited to using 4GB, and even this is questionable due
> > to the kernel being at the top of the address space in sigma0.
> 
> There's no problem with the kernel being on top of the virtual address
> space.  Sigma0 can still *map* the physical memory all up to 4GB.  It
> just can't access it directly from user-level.
> 
> I'm not sure how you've decided that you want to support more than 4GB
> on 32 bit machines.  We've had this discussion a few times before and
> have come up with three solutions:
> 
>   o Have multiple sigma0s, each one backing their own segment of
>     physical memory.  This solution seems very clean at first, but
>     basically means that the L4 mapping model is no longer all that
>     cleanly defined.  It also means that you have to hack the bootup
>     code to support multiple sigma0s.
> 
>   o Make use of unused bits in the 32 bit fpage that allows more than
>     4GB to be expressed.  For example, on IA32, use the bit 10 and 11
>     in the fpage to denote bits 32 and 33 in the address space.  This
>     extends the address space to 16GB.  Or, use the unused bit in the
>     rights field to denote memory above 4GB, only allow 4MB pages
>     above this limit, and use bits 10-22 to denote the bits above 31.
> 
>   o Don't add multiple sigma0s or do fpage hacks.  Instead, make an
>     extension to sigma0 that allows it to switch between segments of
>     4GB, and extend the sigma0 protocol to allow requests for memory
>     within these segments.
> 
> I'm not sure which changes you've made to the API.  I'm also not sure
> how well thought out your statement "it shouldn't be hard to fix this"
> really is, especially considering that you're still unaware of the
> up-to-4GB sigma0 stuff above.  But sure, configuring the generic page
> table code on IA32 to support more page table levels is quite straight
> forward.  I'm just a little amused to hear this statement after
> listening to the moaning and complaining about this before.
> 
> 	eSk