Őőőő, ezt azt jelenti, hogy már nincs is?
Már évek óta. Egyes distro szállítók már igyekeznek a fontosabb binárisokat ET_DYN-re fordítani, annyival jobb a helyzet. :)
minden processz saját kernel stack-kel rendelkezik
A kernel stack az nem "kernel módú kód", hanem adat. ;)
[...] Emiatt volt a 3G/1G felosztás, emiatt elég csak processzváltásonként módosítani a TLB-t, stb.
Ez így van, ezért léteznek a userland pointer dereference hibákat kihasználó kernel exploitok, amelyek ellen véd a PaX/UDEREF. ;)
Mondjuk PaX SEGMEXEC alatt ez igazából 1.5G/1.5G/1G (a 3G userland is ketté van osztva) a VMA mirroring miatt, illetve Ingo úrnak volt olyan - nem túl jól megírt - patche RHEL3-hoz, hogy 4/4 splitet csinált és így volt teljes 4G címtér a userland processzeknek és a kernelnek. Ugyanígy nincs pl. MacOSX-nél a mai napig közös címtér, tehát ott gyakoribb a TLB flush... ;)
Egyébként azt nem tudod véletlenül, hogy az i386-os időkben 3G/1G formában létező processz_virtuális/kernel memóriamegosztás x86_64 esetében milyen arányú (ha lehet egyáltalán erről beszélni)?
Linuxnál fele-fele, 47 bit mindkettő.
Még az KERNEXEC+UDEREF kombináció sem akasztotta ki a Xent
Ha van hardveres virtualizáció támogatás (és a Xen használja is), akkor működnie kell, de mondjuk nincs túltesztelve.