[Gllug] running Xen on another VM

damion.yates at gmail.com damion.yates at gmail.com
Thu Aug 21 23:45:14 UTC 2008


On Wed, 20 Aug 2008, Tim Porter wrote:

> This is interesting, I can understand there being performance issues but
> why shouldn't it work?

I've run Xen on a debian based livecd which I'd booted under vmware.
It was unbelievably slow, I mean seriously unusably slow, but it DID
function.

It is almost certainly a direct result of the way vmware implements
virtualisation on hardware which wasn't designed for it (as others
have mentioned).  There are very good writeups on how this works, one
of the authors of the rather dodgyly named freemware (now plex86) did
a very good white paper (I can't find the original, Google for:
paper-19991129a.txt, I thought that was practically impossible on teh
interweb these days?).  The following ugly presentation contains the
important parts
http://db.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/lawton/lawton.pdf

Basically the non truly virtualisable parts of the Intel and
compatible CPUs need to be dealt with by the fancy PC emulator
products like VMware, this is very expensive, and not perfect.
Fortunately Linux and Windows only do certain things and the products
are written with this in mind.  Also they then spend most of their
time doing things that can be virtualised properly.  Other
virtualisation products on the other hand, are the one thing the
master ones hate the most.

Intel VT and AMD-V fixed this limitation and latest vmware and others
should now no longer need to worry about that.  You know, whilst
reminding myself what these two technologies were called, I found
wikipedia has everything I just tried to say:
http://en.wikipedia.org/wiki/Hardware-assisted_virtualization

I'm particularly interested in this area, and even emailed AMD's
postmaster shortly after they came up with the 64bit extensions, and
after I'd read the .txt white paper I mention above.  They had added
to the kludge that was the 32bit addons, ie a prefix byte before
normal instructions to simply grow the registers (MOV AX,1234, can
become MOV EAX,12345678).  They kept the same simple technique while
Intel tried IA64.  I suggested in another extension that might help
dominate the current giant that was Intel, in helping the
virtualisation products like vmware, by not leaving behind several
mistaken op codes, which give away which mode you're in.  I think I
got a response, but then accidently deleted the email whilst drunk in
a pub reading it on my nokia communicator.  Anyway, I believe I could
be the reason AMD have AMD-V technology now ;)
 
[semi top-posting mess half preserved as it's hard to fix otherwise]
> On Wed, 20 Aug 2008 14:58:51 +0100, Peter Corlett <abuse at cabal.org.uk>
> wrote:
> > [..] in practice it doesn't really work on x86 and you'd be better
> > off scrounging another PC from somewhere and using that.

What does "doesn't really work" mean?

Damion

-- 
Damion Yates - damion.yates at gmail.com
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list