Barrapunto

realmente no es como dicen ningun de los 2, no hay que ver a una VM como un VMWare o un VirtualPC o un VirtualBox, incluso en dichos productos, las VM no pueden emular un procesador diferente, virtualizan.
olvidense de host y guest, en este caso no existe eso, suguiero que vean el codigo de lua y/o python para entender, la memoria no se virtualiza, la maquina virtual solo atienden a instrucciones de su maquina virtual que nada tiene que ver con el procesador en el que estan corriendo, java tampoco virtualiza la memoria, la memoria en ninguna maquina virtual salvo productos de virtualizacion de un ordenador (como ser VMWare, VirtualPC o VirtualBox) no virtualizan la memoria.
no se puede encapsular una direccion de 64bits en 32bits, solo tomando la parte menos significativa, porque la parte significativa no es de un valor unico, sino que dicho valor puede ser diferente segun el area de memoria que ocupe.
el problema es que esto se desprende de DIV, la arquitectura DIV no soporta 64bits (es de DOS) y tampoco los procesadores de esa epoca (salvo algun que otro "monstruo" de la epoca que usaban grandes empresas/entidades bancarias en sus servidores) eran de 64bits.
no hay miedo en bennu para hacer una maquina virtual de 64bits, solo que la maquina actual es de 32bits, la maquina no implica que el manejo de memoria y demas sea virtualizado, en muchos casos se necesitan manipular direcciones de memoria en la maquina virtual a traves del lenguaje, pero esto no es seguro hacerlo si la aplicacion es de 64bits (aunque en la mayoria de los casos los mallocs no dan direcciones de memoria altas), y eso bajo ningun punto de vista es una falla de diseño, son caracteristicas.
por favor, recomiendo encarecidamente que estudien los codigos de los productos mencionados (lua, python) si consideran que fenix/bennu no son de confianza y estan mal diseñados, y entenderan un poco mejor las cosas.
como me gustaria que aparezca Miriam y les explique un poco todo el asunto, ya que confian en ella, nosotros hemos tenido varias charlas tecnicas en privado.
saludos.

¿Cómo que no? En todos los productos de virtualización precisamente se virtualiza la memoria.

Sino, ¿cómo demonios pretendes arrancar máquinas de diferente número de bits, de diferente direccionamiento o de diferente arquitectura?

Joder, ya sabemos que el direccionamiento de una dirección de 64 bits es distinto que el de 32 bits, pero tú SÍ puedes pedir al sistema operativo que te reserve una zona de memoria contigua y así trabajar cómodamente. Y aunque no lo hagas, siempre puedes mapear a mano tú en tu programa o hacer mil chapuzas que se pueden hacer.

Dices: "en muchos casos se necesitan manipular direcciones de memoria en la maquina virtual a traves del lenguaje, pero esto no es seguro hacerlo si la aplicacion es de 64bits (aunque en la mayoria de los casos los mallocs no dan direcciones de memoria altas), y eso bajo ningun punto de vista es una falla de diseño, son caracteristicas."

A mi juicio, lo que dices no tiene ningún sentido, o no te explicas bien, una de dos. Si necesitas manipular una dirección del guest, ¿cuál es el problema? ¿Qué tiene que ver el malloc del host con el del guest? A ver si me entero, creo que pretendes decir que es que la máquina guest en realidad ejecuta código nativo de 32 bits y no lo habéis hecho portable, por lo que a lo mejor el guest está haciendo un malloc() con Lua o similar y resulta que te devuelve una dirección de 64 bits y luego quizás estás manipulando esa dirección suponiendo que es de 32 bits y a veces te puede cascar si el malloc() te mapea la memoria en diferente parte alta. ¿Van por ahí los tiros o qué?

Da igual. Los mecanismos son los mismos, solo que esos productos utilizan soporte hardware para hacer una virtualización muy rápida. Las ideas que hay detrás son poco más o menos las mismas, aunque las posibilidades cambian (en una virtualización al nivel de VMWare, no tienen sentido las caches de trazas, pero sí en una virtualización como la que creo que hacéis en BennuGD).

Sí existe. El host es la máquina real, la que va a ejecutar el código nativo, y el guest es la máquina virtual, la que ejecuta el bytecode. Host y Guest no es solo cosa del S.O. Es terminología, si hay cualquier tipo de máquina virtual, tiene que haber un host donde corra.

Creo que no entiendes lo que significa "virtualizar la memoria". En Java, un programa que tú compilaste en 32bits, corre sobre la JVM de 64bits sin ningún problema. Virtualizar la memoria solo significa que las direcciones que utilice tu programa corriendo en la máquina virtual, tendrán que ser traducidas a direcciones emitibles por la máquina real. Así que te da igual si la máquina virtual es de 32bits o 64bits, cuando leas el opcode de "load", no vas a emitir "mov eax, dirección", sino "mov eax, traduce(dirección)". Como funciona la TLB, vamos.

Era solo una posible idea. Aunque el valor alto no sea siempre el mismo, se trata de tener una tabla de traducción de páginas y que el mecanismo de traducción sea rápido. De todos modos, si tenéis una máquina de pila, no entiendo por qué importan tanto las direcciones de memoria, todo debería estar referido a posiciones de la pila (como en Java).

La máquina virtual de Lua no la he visto nunca, pero estoy familiarizado con la de Java y los módulos de JIT Compiling de LLVM. No estoy dando ideas al azar, estoy pensando en cosas concretas. Obviamente, hasta que no me ponga con el código de la máquina, se me escaparán los pormenores, pero términos generales, no hay ningún problema con que la máquina virtual sea de 32bits y el procesador de 64bits. Para eso se hacen esas máquinas virtuales, para que sean independientes de la arquitectura.