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

[Cedric BAIL <cedric.bail@free.fr>]

> > > 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 ?

I think it will be an overkill to separate them, because you have normally
more data than code.

> > > 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.
 
I don't remind any that are dangerous. Perhaps get and put, but with a trap
on it you can do more things.

> > > 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.

I agree with this point of view, but not so much OS use this.

> > > 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

I am interested by this topic, so did you have any url ?

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