At last! Intel VT-x az E5000 és E7000-es szériában

A Prohardver híre szerint az Intel végre befejezi azt a nonszensz gyakorlatát, hogy a letiltja a virtualizációs utasításkészlet kiegészítést minden olcsóbb processzorában.

A változtatás az Pentium Dual-Core E5300 és E5400, a Core 2 Duo E7400 és E7500, illetve Core 2 Quad Q8300-at érinti, június közepétől.

Egy aprócska gond van csak ezzel: a hír szerint nem változik a típusjelzése az érintett processzoroknak, ezért egy jó ideig keveredni fognak a kereskedőknél és csak gyártási idő alapján lehet eldönteni, hogy pontosan milyet is készülünk megvenni.

(A másik aprócska gond, hogy a Prohardver nem jelöl meg semmiféle forrást, az egyetlen, amit a gugli erre kidobott az ez: http://www.tcmagazine.com/comments.php?shownews=25886&catid=2, mindenki más erre hivatkozik, szóval egyelőre "take it with a grain of salt")

( bsh | 2009. 04. 20., h – 23:15 )

de viszont jókat lehetett röhögni a ph hozzászólásokon. :)

A legdurvább az egészben az, hogy akinek egyáltalán van valami fogalma róla, hogy mi ez, még az is azt hiszi, sőt meg van győződve róla, hogy a VT-x-től gyorsabban fog futni VMware alatt a virtuális gép. Pedig ennek elég keményen az ellenkezője az igaz...
---
Linux is bad juju.

Igen, tudom, lásd lejjebb. Az igazi lökést a hardveres virtualizációnak a shadow page táblát támogató MMU adja, ez viszont az Intelnél még csak a Core i7-ben van (illetve AMD ez ügyben jócskán előrébb jár, a Phenom I.-ekben is már kezdettől fogva ott van). Ezzel együtt már talán kb egy szinten van a kétféle megközelítés, persze alkalmazástól függően nagyon eltérő eredmények is lehetnek. Sok rendszerhívásnál még mindig a szoftveres virtualizáció lesz a jobb, ott ahol pedig sok memóriafoglalás/felszabadítás van, ott inkább a hardveres. De virtualizált MMU-t támogató processzor híján erről nincsenek eredményeim.
---
Linux is bad juju.

Hmm... en eddig ugy tudtam, a VMware kepes kihasznalni a virtualizacios kepesseget, ha van ilyen, ha nincs, akkor pedig sajat modon oldja meg. Tenyleg erdekelne egy reszletesebb indoklas, hogyan mux ez valojaban.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A VMware Workstation-nél a Processors alatt van a "Preferred execution mode"-nál tudod állítani, hogy használja-e. 64 bites guest-nél mindig használja a hardveres kiegészítést, 32 bitesnél a szoftveres binary translation a default, de ott is be lehet kapcsolni a hardverest. (+ még a shadow page tábla hardveres kezelését is, ha van erre támogatás a processzorban)

A különbség oka, hogy a VMware binary translation megoldása (gyakorlatilag egy x86-x86 JIT fordító) egy csomó rendszerhívást nem a virtualizációnál szokásos "trap and emulate" módszerrel oldja meg, mert a CPU-nak az túl sok és hosszú ideig tartó kontextusváltást okozna. Egyszerűen inline kicseréli az elfogandó utasítást egy rövid helyettesítő kódrészlettel, ahol csak lehetséges ez. Ez a ~9 évnyi fejlesztés és optimalizálás eredménye. :)

Hardveres virtualizációnál nincs lehetőség ilyen trükkös optimalizálásra, a guest-ben történő minden rendszerhívás vagy privilégizált utasítás egy teljes CPU trap-et vált ki, annak minden kellemetlen állapotmentési overheadjével együtt. Annyit javul a helyzet, hogy az állapotmentés és visszaállítás (VMCALL/VMRET utasításpár) körülfordulási ideje minden új CPU mag generációval jelentősen csökken, ezért fokozatosan közeledeik a kétféle megoldás teljesítménye egymáshoz, de többnyire még mindig a szoftveres a jobb.
---
Linux is bad juju.

Koszonom a kimerito tajekoztatast. Mindig is tudtam, hogy ha virtualizacio, akkor VMware :-)

Arrol nincs vkinek infoja, hogy ez az ingyenes VMware Server eseteben is igy van-e, vagyis, megfelelo CPU eseteben ki lehet-e hasznalni a CPU virtualizacios lehetosegeit, ha epp valamiert arra lenne szukseg?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.