Miért nincs NX capability a KVM guestben ?

Nos azért mert HIGHMEM4G opció esetén a PAE t bannolták.

Nos ugyebár 2 giga ram van a kasznin, a "host gépen", ez ugye azt jelenti hogy alapvetően az 1g-4g-re úgynevezett HIGHMEM ill. - HIGHMEM4G, hogy pontosabb legyek - beállítással rendelkező kernelt használom, hogy kihasználjam a 2G ramot.

A Kconfigban pedig a X86_PAE szakaszban 2007.07.21-e óta van egy ilyen bejegyzés:

       depends on !HIGHMEM4G

Remek.
Nézzük az indoklást:

PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want NX
or expanded swapspace support without the overhead or instability of
highmem. For these reasons, the following patch divorces CONFIG_X86_PAE
from CONFIG_HIGHMEM64G.

Ez így tökjó, hehe...

Amúgy a !HIGHMEM4G azt jelenti ugyebár, hogy ki lehet választani NOHIGHMEMre és HIGHMEM64G re is amennyire én tudom.

Ugyebár ez a három opció van. Istenkirály, most erre mit mondjak, tök logikus ilyen választási lehetőségekkel ellátni az egységsugarú magamfajtát...

<1 G = no highmem, PAE
1G-4G = highmem4g, no PAE
>4G = highmem64g, PAE

Amúgy ezt már firtatták idén LKML en

Jött a válasz csuklóból:

At least originally, the meaning of the x86 highmem entries were:
No highmem - No highmem, no PAE
HIGHMEM4G - Highmem, no PAE
HIGHMEM64G - Highmem, PAE
X86_PAE and HIGHMEM4G is a bit of a contradiction. I haven't looked
at the logic in detail, or remember offhand if there have been any
weakening of the definitions above; e.g. someone could have implemented
a way to do PAE without highmem, to get access to the NX bits.

A jóember persze nem hagyta magát, említette ezt a jelenséget a vitában itt.

Erre Mingo előállt egy másik válasszal, most erre mondjam azt, hogy 2007ben bannolták a pae-t highmem4g re, most meg 2009 közepe van, és "it just has never really been tested that way.". remek.

A szál még folytatódik, igazán remek a vége is... De ez a lényeg.

Nekem az az érzésem, az említett szál alapján, hogy a !highmem4g helyett inkább highmem et/ !nohighmem-et akartak írni.

Persze válasszak highmem64G t, és dolog nincs vele, jah csak éppen a wine mondjuk segfaultol a hoston érdekes módon, esetleg nem kellene erőltetni. Viszont a PAE mégis kellene, hogy azért a kecske /kvm/ is jóllakjon, és káposzta is megmaradjon /wine/, és mondjuk a memória több mint felét ne kelljen tiltólistára tenni (a nohighmem+pae+resource_64bit kombót inkább nem probáltam ki :D).

A wine mondjuk minden más memóriakezelési buzerálástól is segfaultol, pl. a spéci a 2g/2g től is pl. - ebben is kivették a PAE t de itt meg is indokolták. -, tehát highmem4g vagy semmi.

Lehet, hogy a wine újrafordításával megoldható lenne a highmem64g, dehát inkább asszem fogom az amúgyis szarrágányolt kernelforrásomat, és kiveszem a bant / +1 gányolás mit számít már /

depends on !HIGHMEM4G

a Kconfigból és kész. Aztán majd meglátom.

[Oscon morcos]

Ezek után abban semigen vagyok biztos, hogy a 64bit memory IO resources az nekem annyira szükséges volna 2G ramnál, mint amennyire a KConfig a nyakamba akarja varrni PAE esetére, de majd át kell nézni ezt is hogy miért tették bele.

Majd beszámolok a fejleményekről, a tesztről, hacsak le nem beszél róla valaki, meg lesz helyem a kvm-image nek, meg ilyenek, meg idő estébé...

Nah. kiugattam magam, jóéjt.

U.I.:

A cpuinfo a hoston ír nx-et, de nem ír PAE-t (AMD 64 X2, tehát végülis van nekije enixe).

A guestben viszont már nincs, tehát a kern.logban nem viccből írja, hogy kivette, hanem tényleg kivette az NX cap ot.

Mivel a hostról szedte le a PAE t, valószínűleg nemcsak a KVM el van probléma. De én csak ezt használom (nagyritkán valaminek a tesztelésére)