[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> > > 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.
 
> Nope, without the VMID, one virtual address can point only to a unique
> physical page. The programmer would be an idiot if he/she tries to put
> a different physical page with an active VMID (which interest to do so
> since the purpose of using global page is to see it whatever the virtual
> address space is ?). When not using VMID, it is for sharing the same page
> (physical address) in the same virtual address for all processes without 
> exception :
> virtual and physical kernel pages are the same for all the processes,
> so what is the problem ?
 
> Sorry, but nearly all the SW TLB I saw in most modern CPU has the ability to
> check or not the actual ASID in the entry  (usual name, Address Space ID)
> with the current ASID (whenever you switch a process with a different
> address space, you must change the current ASID). When the global bit is
> set, you instruct the TLB entry to go along with since it must be considered
> as a unique valid virtual to physical address mapping whatever the ASID is
> (kernel page must be in this category). When this bit is unset, you instruct
> the TLB entry to validate the translation only if the ASID of TLB entry
> matchs the current ASID (your XOR operation).

> Ok, now, just imagine that case :
 
> Scheduler Timer (preemptive task-switching) expires, an interrupt is raised:
> - enter kernel code (with ASID:A for process A).
> - elect process B with a different ASID:B.
> - switch task contest
> - switch the current ASID:A for ASID:B --> * BANG *

> What happens ?

If you replace an older ASID by an new one, it's easy you replace the old
entry from the old task, by new entry from the new task.
If you didn't replace an new task, you look in the list of current task and
TLB entry the one that it's too old and never used, and you put your new entry.

It's really a stupid algorithm, but it explain how I see what append.
 
> * TLB has no entry for our kernel page (contains the code where we switched
> the current ASID) with VMID:B, we raise an exception, but our exception must
> also run in another kernel page which is not in TLB :/

For me exception are running with an unactivated TLB, if you need the TLB,
active it, it's all.
 
> It is clear that not only ASID is problematic but even without ASID. If we
> had a HW TLB (that is, we have a full array of valid or invalid page entries
> which TLB can get managed with), there is no problem, since TLB knows where
> to look for the translation (example, IA32 MMU/TLB).

> For SW TLB, we have no way to tell it where to look the translation because
> it is our exception which is in charge.
 
> So, your exception need to run without TLB (that is with physical
> addresses rather than virtual addresses).

> Solutions :
 
> * TLB has no entry for our kernel page (contains the code where we
> switched the current ASID) with VMID:B, we raise an exception in a physical
> address space.
 
> TLB will have two entries with the same virtual and physical address
> but with VMID:A and VMID:B, what a waste ! (I'm speaking about two pages but
> it could be more : the fact is that you would have much more cache misses
> because of possible excessive discarding entries for kernel pages with
> different VMID).

Not a wast, you can have two different type of protection bits. This is useful,
and you software can do more thing to protect form problem.

> * kernel code is always running in physical address space (never using
> TLB, as suggested by Whigee)

> Ok, but what is the point to have supervisor/user bit ?????

I think I have the same question.


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