[Discuss] VMWare Player question

[gaf at blu.org (Jerry Feldman)]

X86 emulators have existed for a very long time as have other
architectures. I used a PC emulator way back on a Digital project where
I only had an Ultrix workstation. We also had the capability of running
x86 on NT Alpha. The NT/Alpha emulator was smart enough to actually
write native code on the fly so the application could, in theory,
perform quite well. However, with tools like this, developers had no
incentive to develop native Alpha applications.

But, the problem with doing X86_64 on a 32-bit CPU has a lot of
interesting issues. While many of the instructions are the same, the
register sizes are different and you have more registers on x86_64, and
many other differences. VMWare's virtualization solutions tend to be
very good. I'm finding that I can run stuff on my VM (hosted on a
dedicated ESX box) with performance that feels native. I have not
performed any performance testing but we are starting to max out that
box and we have asked for a twin so we can do some other neat VMWare
things.

In any case the reason for my question was that we have to make a USB
drive VM image that our class members can use offline, and the VM that
they wanted me to configure was a clone of the attendee VM with the
network elements removed (such as NIS and autoFS). While most of us in
this office have newer x86_64 Thinkpads, I have an ancient T60 32-bit
CPU, so I had to rely on a coworker. But I was still somewhat unsure at
the time whether VMWarePlayer running on a 32-bit OS would allow a
64-bit guest. The answer is yes as long as the underlying CPU is an
x86_64 with the appropriate virtualization bits turned on. Most laptops
do not have this capability, but Thinkpads do.

On 10/20/2011 12:52 PM, Bill Bogstad wrote:
> On Wed, Oct 19, 2011 at 8:20 PM, Richard Pieri <richard.pieri at gmail.com> wrote:
>> On Oct 18, 2011, at 8:56 PM, Edward Ned Harvey wrote:
>>> Nothing will support a 64bit guest on a 32bit host.
>> I digress here, because this is not strictly true.  IBM devised a method for running some 64-bit applications on 32-bit AIX servers.  I digress because this was not virtualization.  It was a clever use of a wrapper that mapped 64-bit functions to their 32-bit counterparts and then mapped the returns back as 64-bit data.  It was terribly slow, totally unsuited for production use.  IBM did it for developers to test their code given older hardware.
>>
>> VMware could have made it happen.  Back before VT-x and AMD-V, VMware didn't really virtualize the x86.  VMware *emulated* the x86.  Ask Google about trap-and-emulate and why it doesn't work on the Intel architecture.
> I'm not sure how you are defining "emulate" here.   As I understand
> it, most x86 instructions were executed directly by the CPU even in
> the pre VT-X/AMD-V days for VMware and most similar programs.
> Instructions that accessed hardware and other specialized instructions
> were either trapped or replaced in line by calls to vmware code.
> Full emulation of a baroque architecture like the x86 would have been
> incredibly slow.  This web page
>
> http://www.vmware.com/virtualization/history.html
>
> appears to confirm my recollection for VMware for x86.
>
> Doing AMD64 on x86 only cpus would have required full emulation and
> would have been equally painful to full emulation of x86 code.  I
> believe that the first products that did virtualization for AMD64
> initially did the same thing as for x86 code: only trap/emulate a few
> instructions and execute the rest natively.   VT-X/AMD-V made it
> easier to do AMD64 virtualization at acceptable speeds, but wasn't
> required.  This wikipedia article
>
> http://en.wikipedia.org/wiki/X86_virtualization
>
> implies that the first AMD 64bit cpus did have some issues with using
> the software virtualization route, but that AMD added a few features
> to make it technically possible to do so.  Both Intel and AMD
> eventually added much better support via VT-X/AMD-V, but at least some
> AMD 64 bit cpus could support software assisted virtualization without
> it.


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90