Re: l4ka Digest, Vol 30, Issue 12
Espen Skoglund <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.l4ka.general |
|---|---|
| Message-ID | <[email protected]> |
[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