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

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

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

* 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 :/

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

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



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