Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
They were planning to be able to run Windows unmodified with this
release, but can't see a word of it in the announcement. Does that mean
they did not manage yet?
Posted Dec 7, 2005 0:01 UTC (Wed) by marineam (subscriber, #28387)
I've seen refrence to the possibility of running windows on Xen by using win4lin, but I know nothing about that.
Posted Dec 7, 2005 0:03 UTC (Wed) by drag (subscriber, #31333)
x86 is very difficult to abstract compared to other systems. IBM has built their mainframes with abstractions and such for a couple decades now and since it's designed for this from the ground up it's much more efficient. (We are running a OS that dates from the 80's on IBM hardware that dates from the late 90's using hardware and software technology that PCs are just getting. It's quite impressive.)
So these hardware 'fixes' to assist Xen in abstracting the x86 and x86-64 platform won't come into effect until the next generation of Intel and AMD proccessors are out on the market. The article mentions support for this stuff...
Of course, even though Intel and AMD worked specificly with Xen to get support for their hardware-assisted abstraction solutions other virtual machine stuff like VMWare can take advantage of it also.
Posted Dec 7, 2005 3:28 UTC (Wed) by aliguori (subscriber, #30636)
If you really want to be surprised, read the VT or Pacifica specs and then read this article describing 390 virtualization from the early 90s. There's almost a 1-1 mapping. At a talk recently, a fellow from AMD had mentioned that the reason the VT and Pacifica specs are so close to each other is that both companies had read the old IBM systems journals and based their implementations on it.
What's old is new right :-)
Posted Dec 7, 2005 0:11 UTC (Wed) by xoddam (subscriber, #2322)
Vitualization support in hardware
Posted Dec 9, 2005 18:13 UTC (Fri) by giraffedata (subscriber, #1954)
IBM System/360 was 40 years ago, and the first virtual machine implementation on top of it came a few years later. The very first S/360 couldn't do virtual machines because it lacked virtual memory.
I should clarify that when I say "virtual machine" here, I mean the kind where the virtual machine has the same architecture as the underlying real one, so you can run unmodified software meant for the real machine on the virtual one.
But S/360 wasn't designed with virtual machines in mind. What made S/360 amenable to virtualization where IA32 is not is simply the fact that it cleanly isolated user mode, which it did for other philosophical reasons. For example, on IA32 if a program in user mode tries to update a control register, it traps. But if it tries to read a control register, the CPU doesn't recognize a significant security exposure, so it succeeds. On S/360, the read of the control register traps too.
Traps for stuff that is shared by multiple processes are essential if you want the processes to see separate machines, because they give the hypervisor a chance to show a different version to each process.
It worked great, but wasn't as efficient as it could be. After the market for IBM's virtual machine operating system took off (and not because people liked virtual machines; just because it was IBM's best option for an interactive computer system), lots of stuff was architected into future CPUs of the S/360 line specifically to help with virtualization.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds