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

[Michael Riepe <michael@stud.uni-hannover.de>]

On Sun, Jul 14, 2002 at 08:41:01PM +0200, Christophe Avoinne wrote:
> 
> ----- 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.

But you can still use the same TLB entry for both operations.

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

That doesn't make sense. The VMID is part of the primary key for TLB
lookups. If you ignore it, the keys are no longer unique - the same
virtual address may pointer to several different physical pages.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/