Re: [f-cpu] little feed-back from the libre softawre meeting

["Christophe Avoinne" <christophe.avoinne@laposte.net>]

----- Original Message -----
From: "Michael Riepe" <michael@stud.uni-hannover.de>
To: <f-cpu@seul.org>
Sent: Sunday, July 14, 2002 12:54 AM
Subject: Re: [f-cpu] little feed-back from the libre softawre meeting


> On Sat, Jul 13, 2002 at 06:28:35PM +0200, Christophe Avoinne wrote:
> [...]
> > 1) Permission bits : rwx
> >     - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and
> > "store" operations), but what could be the meaning of 'x' ?
> >     - 'x' is relevant for code memory (ICACHE, instruction "load"
> > operations, but what could be the meaning of 'r' or 'w' ?.
> > It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x'
bit.
> > But my question is about knowing if there would be two different TLB or
an
> > unified one ?
>
> Different TLB entries for data and code `views' of the same page of
> memory? That may introduce yet another aliasing problem.
>
> BTW: why should a page NOT be both writable and executable?

When reading or writing a code segment, you use "load"/"store" instructions
to do so, so it is clearly a DCACHE operation even if page contains a code
When executing (that is reading with ICACHE), it is the scheduler which
reads, so it is clearly a ICACHE operation.

So if you have separate TLB entries for ICACHE and DCACHE, it makes nonsense
to speak about a page writable in a TLB entry for ICACHE. Do you understand
what I mean now ?

Now, the problem is to know if the entries for TLB are unified for both
ICACHE or DCACHE ?

>
> > 2) Supervisor/user bits :
> >     - 's' : some instructions which are considered as priviledged
requires
> > this bit set.
>
> Inside the TLB?
>

It is just a question. Usually in ISA there is some instructions too
dangerous to be handled by an application.

> > 3) How to share code between memory spaces, especially for kernel or
shared
> > library codes :
> >     - code pages can be shared between space memories; using a bit to
tell
> > if VMID must be checked for this page allows kernel code or shared
library
> > to run without excessive cache flushing because of a VMID differs
between
> > two processes.
>
> In reality, processes sharing a code page will have individual TLB entries
> for it, with different VMIDs. The page is shared, the TLB entry isn't.
>
???
you use a SW tlb, that is ? so you'd better to avoid having several entries
pointed out on the same kernel page because of different VMID. Try to
imagine 8 actives processes, you spoiled 8 entries whereas you can just have
one entrie for any processes. If you look at the most of SW TLB they have a
bit to to tell if we want to check VMID or bypass. If, unhappily, you switch
a new process (that is a new VMID), your running kernel code would be
invalidated because of the VMID. It is stupid.

> > 6) Inheritance bits : mostly a software issue I think, so I wouldn't
detail
> > them here.
>
> Who inherits what?

Rights for access on page for children, something like : deny, one-level
inheritance,deep inheritance, etc.

My memory is leaking. I don't remember if it is an issue I read in L4 or
something else. Anyway, it doesn't matter because I think it is clearly a SW
issue which occurs when you want to share page between father and children.
A very interestion point but off-topic here since I don't think we need
extra bits for them in TLB

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/