linux - hvad hvis køre 2 type 2 VMX hypervisorer i en x86 vært?

Indlæg af Hanne Mølgaard Plasc

Problem



I Intel VMX-operationer skal man først ringe VMXON(VMXON\_REGION) for at aktivere VMX i CPU'en, og derefter VMPTRLD(VMCS\_REGION) osv.

Her kommer mit spørgsmål.

Hvad hvis to hostede hypervisorer kører på samme tid i en X86 vært?
Den første VMXON går godt, men anden VMXON vil gå i stykker.

Og 2 hypervisorer kan kalde VMPTRLD(VMCS\_REGION\_a) og VMPTRLD(VMCS\_REGION\_b), den nuværende VMCS i CPU'en ændres, vil den kollapse den anden hypervisor eller de kan eksistere sammen med hinanden?

Fra min SDM-læsning tror jeg ikke, at de kan eksistere, måske har jeg igen savnet noget vigtigt.


Hjælp venligst med at præcisere dette.

Bedste reference


Du har ret, den nuværende tilstand af Intel VT-x tillader ikke samtidig drift af to uafhængige virtuelle maskinmonitorer (VMM) ved siden af ​​hinanden. De vil skabe en konflikt med systemressourcer, der vil føre til udefineret adfærd, herunder nedbrud af virtuelle maskiner (VM), hænger eller genstarter, måske data korruption.


For eksempel er det usikkert at indlæse kernel drivere til forskellige visualiseringsløsninger samtidig, ikke engang at starte VM'er. Jeg har oplevet problemer, når f.eks. KVM og Virtualbox eller KVM og Simics VMP blev fyldt sammen.


Det er umuligt for en VMM at sikkert blokere indlæsning eller drift af en anden.
Det er endog problematisk for en VMM at påvise pålidelig tilstedeværelse af andre VMM'er, da VMXON/VMXOFF kan udføres dynamisk under operativsystemoperativsystemet (OS), og der findes ingen hardware ressource, der kan fungere som et gensidigt eksklusivt objekt eller en lås til virtualisering ressourcer.


Den eneste tilgang, der vil fungere med moderne hardware, er, at et værts-OS skal tilvejebringe en API til formidling af anmodninger til underliggende virtualiseringsressourcer (VMXON/VMXOFF, VMPTRLD, VMLAUNCH/VMRESUME osv.) Og for alle VMM'er at blive enige om at bruge denne API. Sådanne faciliteter findes for Apple Mac OS X og siden for nylig til Microsoft Windows-systemer. Men man kan hævde, at disse API'er er noget begrænsende for en VMM-forfatter.