Re: Kernel support for peer-to-peer protection models...

[Andi Kleen]

"Ivan Godard" <igodard@xxxxxxxxxxx> writes:

> We're a processor startup with a new architecture that we will be porting
> Linux to. The bulk of the port will be straightforward (well, you know what
> I mean), except for the protection model supported by the hardware.  How
> would you extend/mod the kernel if you had hardware that:
> 
> 1) had a large number of distinguishable address spaces

Large or unlimited? If not unlimited you may still run into
problems when you give each process such an address space.
Limiting the number of processes is probably not an option.

> 2) any running code had two of these (code and data environment) it could
> use arbitrarily, but access to addresses in others was arbitrarily protected
> 3) flat, unified virtual addresses (64 bit) so that pointers, including
> inter-space pointers, have the same representation in all spaces

You mean Address 0 is only accessible from Address space 0, but not 
from Space 1 ?

Maybe you can give each process an different address range, but AFAIK
the only people who have done this before are users of non MMU architectures.
It will probably require som changes in the portable part of the code.
Also porting glibc's ld.so to this will be likely no-fun.

> 4) no "supervisor mode"
> 5) inter-space references require grant of access (transitive) by the
> accessed space; grants can be entire space or any contiguous subspace

Sounds like the only sane way to handle (4) would be to give the kernel
an own address space with the necessary grants to access everything.
However this will require an address space switch for every system call.
But there is no way around it, linux requires a "shared" kernel mapping
at least for part of the kernel memory ("lowmem")

Overall it sounds like your architecture is not very well suited to 
run Linux.

> 10) Drivers can have their own individual space(s) distinct from those of
> the kernel and the apps. Buggy drivers cannot crash the kernel.

At least you would need to use your own drivers (I believe the IBM
iSeries and s390/VM port does it kind of). If your CPU has generic PCI
slots this will be a lot of work. Without it it will be lots of work too,
but at least the number of drivers required is limited.

> Is this model so alien to the existing Kernel that the best approach is to

It is definitely alien.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/