View Full Version : virtual machine
salve, cercavo una virtual machine per x86 (ovviamente da far girare su un x86) possibilmente non emulata e possibilmente free (:D), ma il requisito essenziale è che il file dove scrive il contenuto dell'hard disk non deve avere nessun formato particolare, deve essere raw data, un file con dentro direttamente il contenuto dell'hard disk :)
ne esistono? me ne sapete consigliare? grazie :)
PS: altrimentiva bene pure se ha un formato, purché sia noto però, e possibilmente non troppo complesso :cry:
salve, cercavo una virtual machine per x86 (ovviamente da far girare su un x86) possibilmente non emulata e possibilmente free (:D), ma il requisito essenziale è che il file dove scrive il contenuto dell'hard disk non deve avere nessun formato particolare, deve essere raw data, un file con dentro direttamente il contenuto dell'hard disk :)
ne esistono? me ne sapete consigliare? grazie :)
PS: altrimentiva bene pure se ha un formato, purché sia noto però, e possibilmente non troppo complesso :cry:
Prova a dare un occhiata a qemu. http://fabrice.bellard.free.fr/qemu/
ciao ;)
perfetto, grazie VICIUS :)
in Qemu è possibile scegliere il formato dell'harddisk ed è possibile naturalmente scegliere raw format :)
thx
cdimauro
03-10-2005, 11:13
Comunque QEmu è un emulatore... ;)
Comunque QEmu è un emulatore... ;)
Non sono la stessa cosa ?
ciao ;)
vero, è un emulatore, ma è possibile velocizzare le parti di codice "sicuro" eseguendole direttamente; me lo farò andare bene. :)
cdimauro
04-10-2005, 11:04
Non sono la stessa cosa ?
ciao ;)
No, una macchina virtuale non ha alcuna emulazione al suo interno: esegue il codice nativamente. Le uniche cose che vengono "trappate" sono le istruzioni di I/O e quelle privilegiate.
Ciao. :)
No, una macchina virtuale non ha alcuna emulazione al suo interno: esegue il codice nativamente. Le uniche cose che vengono "trappate" sono le istruzioni di I/O e quelle privilegiate.
Ciao. :)
Se non ho capito male con quel modulo addizionale dovrebbe essere possibile anche su qemu quindi non dovrebbe avere problemi.
ciao ;)
Fenomeno85
04-10-2005, 19:30
vmware :stordita:
~§~ Sempre E Solo Lei ~§~
vmware workstation so che è ottimo, ma l'hard disk è possibile farlo in formato raw?
cdimauro
05-10-2005, 12:25
Se non ho capito male con quel modulo addizionale dovrebbe essere possibile anche su qemu quindi non dovrebbe avere problemi.
ciao ;)
Non sapevo dell'esistenza di questo meraviglioso componente! :sbav: :sbav: :sbav:
Così effettivamente QEMU diventa molto simile a VMWare & co... Velocità di esecuzione MOLTO elevata... :)
Grazie!!! :)
be', molto elevata no: considera che nemmeno un MOV può essere eseguito direttamente: se fosse eseguito direttamente il processo emulatore andrebbe in crash dopo breve. però è possibile eseguire direttamente tutte le istruzioni aritmetico-logiche, floating point, e molte altre; inoltre, se l'emulatore è provvisto di un driver, è possibile far corrispondere le memory ranges delle periferiche emulate con quelle reali, cosicché ad esempio l'esecuzione di un MOV sulla memoria video sia (quasi) diretto (sempre che la finestra sia a tutto schermo ovviamente).
io uso Virtual PC 2004 su Windows e QEmu su Linux... :)
anche io usavo Virtual PC, ma usa un formato proprietario; comunque adesso mi sono stabilito su Qemu (che è ottimo perché fa scegliere il formato), e se avrò problemi userò vmware workstation, quindi sono a posto :)
anche io usavo Virtual PC, ma usa un formato proprietario; comunque adesso mi sono stabilito su Qemu (che è ottimo perché fa scegliere il formato), e se avrò problemi userò vmware workstation, quindi sono a posto :)
ma VMWare WS è gratuito :mbe: ?!
ma VMWare WS è gratuito :mbe: ?! ma ceeeeeeeeerto... che no! :D
cdimauro
06-10-2005, 16:04
be', molto elevata no: considera che nemmeno un MOV può essere eseguito direttamente: se fosse eseguito direttamente il processo emulatore andrebbe in crash dopo breve. però è possibile eseguire direttamente tutte le istruzioni aritmetico-logiche, floating point, e molte altre; inoltre, se l'emulatore è provvisto di un driver, è possibile far corrispondere le memory ranges delle periferiche emulate con quelle reali, cosicché ad esempio l'esecuzione di un MOV sulla memoria video sia (quasi) diretto (sempre che la finestra sia a tutto schermo ovviamente).
Mi sembra che col modulo di cui ha parlato VICIUS, QEmu si comporti comporti invece come gli altri "virtualizzatori". Quindi il codice dovrebbe essere eseguito normalmente -> direttamente, fatta eccezione per il trapping di cui parlavo prima. Ovviamente il trapping si verifica anche nel caso di page fault (che penso verrà usato dal "virtualizzatore" per intercettare l'accesso a particolari zone di memoria, come potrebbe essere quella della scheda video CGA/VGA).
Il tutto IMHO, chiaramente.
Mi sembra che col modulo di cui ha parlato VICIUS, QEmu si comporti comporti invece come gli altri "virtualizzatori". Quindi il codice dovrebbe essere eseguito normalmente -> direttamente, fatta eccezione per il trapping di cui parlavo prima. Ovviamente il trapping si verifica anche nel caso di page fault (che penso verrà usato dal "virtualizzatore" per intercettare l'accesso a particolari zone di memoria, come potrebbe essere quella della scheda video CGA/VGA).
Il tutto IMHO, chiaramente. come la mettiamo col fatto che nel processo QEmu potrebbero esserci allocate delle pagine i cui indirizzi coincidono con le ranges occupate da perferiche hardware come la scheda video? :D
se il MOV viene eseguito direttamente non solo il sistema emulato non riuscirà a scrivere nella memoria video (cosa che doveva fare) ma danneggerà anche i dati del processo QEmu. :p
i MOV non possono essere eseguiti direttamente: vanno decifrati, va simulata la segmentazione e la paginazione, va ricavato l'indirizzo fisico finale, e se questo va a finire in un'area di memoria di una periferica hardware bisogna fare richiesta al driver, altrimenti bisogna scrivere/leggere nella/dalla RAM simulata.
Fenomeno85
06-10-2005, 18:56
ma VMWare WS è gratuito :mbe: ?!
no però almeno non ti rompi le palle a installare su linux facendo partizione, modificare boot e sprecare spazio.
~§~ Sempre E Solo Lei ~§~
come la mettiamo col fatto che nel processo QEmu potrebbero esserci allocate delle pagine i cui indirizzi coincidono con le ranges occupate da perferiche hardware come la scheda video? :D
se il MOV viene eseguito direttamente non solo il sistema emulato non riuscirà a scrivere nella memoria video (cosa che doveva fare) ma danneggerà anche i dati del processo QEmu. :p
i MOV non possono essere eseguiti direttamente: vanno decifrati, va simulata la segmentazione e la paginazione, va ricavato l'indirizzo fisico finale, e se questo va a finire in un'area di memoria di una periferica hardware bisogna fare richiesta al driver, altrimenti bisogna scrivere/leggere nella/dalla RAM simulata.
Non è che magari gira su un'altro processo ?
no però almeno non ti rompi le palle a installare su linux facendo partizione, modificare boot e sprecare spazio.
~§~ Sempre E Solo Lei ~§~
guarda che io linux lo uso sul secondo PC dove c'è solo lui :Prrr: e poi non è un rompimento di palle LINUX...
Non è che magari gira su un'altro processo ? se l'emulazione girà su un altro processo rischi comunque di sovrascrivere l'eseguibile iniziale o comunque kernel32.dll
se l'emulazione girà su un altro processo rischi comunque di sovrascrivere l'eseguibile iniziale o comunque kernel32.dll
Perchè scusa ??!? Sarà l'eseguibile stesso a non sovrascriversi sapendo come lavorare con la memoria vista linearmente... Il rischio di sovrascrivere l'eseguibile c'è allora in qualsiasi programma...
Perchè scusa ??!? Sarà l'eseguibile stesso a non sovrascriversi sapendo come lavorare con la memoria vista linearmente... Il rischio di sovrascrivere l'eseguibile c'è allora in qualsiasi programma... infatti in qualsiasi programma rischi di sovrascrivere la sezione di dati di kernel32.dll o altre sezioni non protette di altri moduli
i MOV non possono essere eseguiti direttamente: vanno decifrati, va simulata la segmentazione e la paginazione, va ricavato l'indirizzo fisico finale, e se questo va a finire in un'area di memoria di una periferica hardware bisogna fare richiesta al driver, altrimenti bisogna scrivere/leggere nella/dalla RAM simulata.
Non pensavo al fatto delle varie modalità di indirizzamento e funzionamento... Comunque secondo me si potrebbe lo stesso fare... Tramite la trap interrupt appena eseguita una istruzione si va a vedere se l'istruzione è andata a scrivere dove non si voleva o dove bisogna far reagire la macchina virtuale (ad esempio la memoria video)...
Comnuque hai ragione...non si può evitare di andare a decifrare (e tradurre) i mov...
cdimauro
07-10-2005, 11:58
come la mettiamo col fatto che nel processo QEmu potrebbero esserci allocate delle pagine i cui indirizzi coincidono con le ranges occupate da perferiche hardware come la scheda video? :D
se il MOV viene eseguito direttamente non solo il sistema emulato non riuscirà a scrivere nella memoria video (cosa che doveva fare) ma danneggerà anche i dati del processo QEmu. :p
i MOV non possono essere eseguiti direttamente: vanno decifrati, va simulata la segmentazione e la paginazione, va ricavato l'indirizzo fisico finale, e se questo va a finire in un'area di memoria di una periferica hardware bisogna fare richiesta al driver, altrimenti bisogna scrivere/leggere nella/dalla RAM simulata.
A mio avviso la macchina virtuale gira su un processo a sé stante, controllato dal processo principale di QNX. Come diceva cionci.
Domanda: come farebbero altrimenti a girare le DOS-Box di OS/2, Windows NT, Linux (e altro)? Risulterebbero MOLTO lente. E lo stesso si verificherebbe con i "virtualizzatori" già esistenti (VMWare, VirtualPC). Come fai a intercettare soltanto le MOV? Un controllo di questo tipo è troppo dispendioso in termini computazionali.
Invece ti accorgi che la velocità di esecuzione è di poco inferiore a quella reale, eseguendo applicazioni che eseguono dei calcoli, mentre i rallentamenti si notano lavorando in finestra (perché gli accessi al frame buffer vengono intercettati e "smistati" al s.o. "ospite"), perché a pieno schermo il sistema emulato è un fulmine.
Non è un caso se quel "plugin" per QEMU richieda una patch al kernel per Linux, e un apposito driver per Windows 2000 e XP.
E' probabile che in questo modo venga "patchato" il kernel per far sì che sia possibile manipolare con una certa libertà la tabella delle pagine del processo della macchina virtuale, e intercettate e gestite velocemente le eccezioni derivanti da richieste di I/O o da segment / page fault.
Il tutto sempre IMHO. ;)
E' probabile che in questo modo venga "patchato" il kernel per far sì che sia possibile manipolare con una certa libertà la tabella delle pagine del processo della macchina virtuale, e intercettate e gestite velocemente le eccezioni derivanti da richieste di I/O o da segment / page fault.
Comunque pensa se questa DOS box funzionasse a 16 bit con la segmentazione... Chi la fa la traduzione degli indirizzi ? La CPU può lavorare conteporaneamente in modalità reale e protetta ? O magari switchare dall'una all'altra appena si ha un task switch ? Se la risposta è sì allora potrebbe funzionare...se è no, ci deve essere qualche meccanismo che permette di tradurre gli indirizzi (e non solo delle mov)... Penso che la DOS box di Windows NT sia qualcosa di più semplice, in quanto gli viene riservato un tot di memoria su cui può lavorare, senza problemi di sovrascrittura di arree già usate...
per questa DOS Box (se ho ben capito che è) basta fare un processo in modalità virtuale 86; comunque imho qualsiasi istruzione x86 da emulare su un x86 che acceda alla memoria in qualche modo (e in qualsiasi modalità del processore), deve essere necessariamente interpretata, anche se poi è possibile velocizzare la sua esecuzione con diversi accorgimenti, a seconda dei casi.
fantoibed
07-10-2005, 21:38
Per par condicio, ricordiamoci anche di bochs (http://bochs.sourceforge.net/) e dosemu (http://www.dosemu.org/). Entrambi possono usare un disk image file.
cdimauro
10-10-2005, 14:31
Comunque pensa se questa DOS box funzionasse a 16 bit con la segmentazione... Chi la fa la traduzione degli indirizzi ? La CPU può lavorare conteporaneamente in modalità reale e protetta ? O magari switchare dall'una all'altra appena si ha un task switch ? Se la risposta è sì allora potrebbe funzionare...se è no, ci deve essere qualche meccanismo che permette di tradurre gli indirizzi (e non solo delle mov)...
Il 386 può lavorare in real mode o in modalità protetta, e in quest'ultimo caso può far girare delle applicazioni in virtual mode 86, quindi come i vecchi 8086.
Penso che la DOS box di Windows NT sia qualcosa di più semplice, in quanto gli viene riservato un tot di memoria su cui può lavorare, senza problemi di sovrascrittura di arree già usate...
Girano in virtual mode 86, e tutte IN, OUT, INSB, OUTSB, CLI, STI, ecc. sono virtualizzate (trappate e gestite dal kernel).
cdimauro
10-10-2005, 14:43
per questa DOS Box (se ho ben capito che è) basta fare un processo in modalità virtuale 86;
Esattamente. E puoi anche fargli condividere delle pagine di memoria con altri processi che lavorano in modalità protetta.
comunque imho qualsiasi istruzione x86 da emulare su un x86 che acceda alla memoria in qualche modo (e in qualsiasi modalità del processore), deve essere necessariamente interpretata, anche se poi è possibile velocizzare la sua esecuzione con diversi accorgimenti, a seconda dei casi.
Sarebbe comunque troppo lento, fidati. Innanzitutto dovresti decodificare le istruzioni per riconoscerne il tipo, e questo è già un processo abbastanza lento. Poi dovresti generarti il codice equivalente (tramite un compilatore JIT) e "farcire" quelle che accedono alla memoria con dei controlli opportuni, in moda da "intrappolare" l'accesso ad aree non consentite. Un casino.
Invece con un virtualizzatore i rallentamenti si verificano soltanto quando si utilizzano le istruzioni di I/O o quelle privilegiate, che vengono "trappate" e gestite dal processo di controllo. Anche le istruzioni che accedono alla memoria vengono eseguite direttamente, senza alcun rallentamento, fatta eccezione nei casi di page fault.
Puoi fare una prova per verificarlo. Prova a comprimere un file in un PC, e nello stesso ma con una macchina virtuale: vedrai che il tempo di esecuzione rimarrà quasi lo stesso. E tutto ciò nonostante si facciano parecchi accessi alla memoria (gli algoritmi di compressione di tipo LZ77/78 ne fanno parecchi).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.