[Linux - KVM] Welk processor family voor guest?

[Keiichi]

In een KVM guest ben ik kernel aan het compilen. Hiervoor configureer ik de kernel zelf (Althans, ik haal alles eruit wat ik werkelijk niet nodig heb).

Alleen vraag ik me af bij de optie processor family welke de meeste efficiente is die gekozen kan worden. Qemu(kvm) is gestart met standaard CPU optie, dus 'QEMU Virtual CPU version 0.9.1' is de die de guest ziet.

Welke processor family kan ik het beste kiezen? (Ik kan altijd op safe spelen om 386 te selecteren )

[kalizec]

Ik 'meen' dat je voor een gevirtualiseerd OS het beste de processor kunt kiezen die qua functionaliteit het dichtst bij de onderliggende CPU ligt. Immers instructies worden 'doorgeschoven' en alleen waar nodig vertaald. Dat betekent dat je niet meer moet, maar ook niet minder hoeft te vragen dan de onderliggende CPU.

[Keiichi]

kalizec schreef op dinsdag 20 januari 2009 @ 08:58:
Ik 'meen' dat je voor een gevirtualiseerd OS het beste de processor kunt kiezen die qua functionaliteit het dichtst bij de onderliggende CPU ligt. Immers instructies worden 'doorgeschoven' en alleen waar nodig vertaald. Dat betekent dat je niet meer moet, maar ook niet minder hoeft te vragen dan de onderliggende CPU.

Ik geloof dat het niet zo werkt bij KVM (qemu)

De flags bij de guest zijn 'fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 nx lm pni'

Bij de host zijn ze 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow vnmi flexpriority'

Het mag denk al voor zich spreken dat core2 selecteren voor de guest niet handig is, omdat deze eigenlijk ook geen beschikking heeft over bijvoorbeeld 'ssse3'.

(Als ik met vmware gewerkt zou hebben, zou het wel opgaan om in de guest flags voor de CPU te gebruiken van de onderliggende hardware.

[kalizec]

Keiichi schreef op dinsdag 20 januari 2009 @ 09:40:
Het mag denk al voor zich spreken dat core2 selecteren voor de guest niet handig is, omdat deze eigenlijk ook geen beschikking heeft over bijvoorbeeld 'ssse3'.

Als die onderliggende CPU een Core2 is en het host OS heeft support voor SSSE3 dan kun je dat prima ook in de guest-OS enablen (imho).

Of zijn we nu langs elkaar heen aan het praten?

[Keiichi]

kalizec schreef op dinsdag 20 januari 2009 @ 09:50:
[...]


Als die onderliggende CPU een Core2 is en het host OS heeft support voor SSSE3 dan kun je dat prima ook in de guest-OS enablen (imho).

Of zijn we nu langs elkaar heen aan het praten?

KVM blijft de CPU voor de guest altijd nog emuleren, waardoor maar een beperkte aantal instructies mogelijk zijn.

[Paulusbrand]

Ik vond het wel een interessante vraag.

Na wat spitten:

By itself, KVM does not perform any emulation. Instead, a user-space program uses the /dev/kvm interface to set up the guest VM's address space, feed it simulated I/O and map its video display back onto the host's. Currently, the only such program that does this is a modified version of QEMU.

Bron:
Wiki

Het lijkt me dus verstandig een QEMU Virtual CPU te kiezen.

[ Voor 26% gewijzigd door Paulusbrand op 20-01-2009 10:48 ]

[Verwijderd]

Euhm misschien is het wat onduidelijk weer gegeven op het web en met name wikipedia ;-)

KVM is een accelartor in de zin dat het gebruik maakt van een instructie set die gevonden kan worden op intel en AMD cpu's. Zodat er geen vertaal slag nodig is. Verder is het een gewone (wat heet gewoon) hypervisor zoals Xen bijvoorbeeld. Op 1 voorwaard na; zonder de speciale instructies doet ie het niet

QEMU is een emulator; die alle (bijna?) CPU archs kan na bootsen. QEMU *kan* KVM gebruiken om de 'vertaa lslag' sneller te laten gaan. Dit geldt dan alleen van platformA naar platformA. Als je van A naar B gaat zal QEMU alles op de oude manier vertalen.

(A is dan intel of amd en van amd naar intel werkt ook)