From: ted@ags.ga.erg.sri.com.foo.bar.com Newsgroups: alt.folklore.computers Subject: Why can't more CPUs virtualize themselves? Date: 28 Sep 1998 17:30:41 GMT Organization: SRI International Lines: 17 Message-ID: <6uoh41$9se$1@news3.infoave.net> NNTP-Posting-Host: solabel1.ga.erg.sri.com X-Trace: news3.infoave.net 907003841 10126 192.26.244.10 (28 Sep 1998 17:30:41 GMT) X-Complaints-To: usenet@news3.infoave.net NNTP-Posting-Date: 28 Sep 1998 17:30:41 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news-peer.sprintlink.net!news-backup-east.sprintlink.net!news.sprintlink.net!165.166.15.4!news3.infoave.net!not-for-mail Does anyone know why CPUs that could virtualize themselves never really caught on? I know the IBM 370 could do it, and that the VM operating system took full advantage of the concept, and I know the 386 (and higher) chips could virtualize an 8086... So why didn't Intel ever take the next step to a Pentium that could virtualize itself (or at least a 386..). Why didn't any other chip makers? I guess it definitely wouldn't be RISC, but then something like the 68000 series wasn't RISC anyway.. Were there any others besides the 370? Ted -- --- Remove the .foo.bar.com to reply ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: Why can't more CPUs virtualize themselves? Date: 28 Sep 1998 13:06:09 -0700 Organization: Wheeler&Wheeler Lines: 26 Message-ID: References: <6uoh41$9se$1@news3.infoave.net> <6uoouu$f9q$1@flood.weeg.uiowa.edu> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-18.garlic.com X-Newsreader: Gnus v5.6.42/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.internetmci.com!209.244.253.199!newsfeed.xcom.net!news.shore.net!uunet!in4.uu.net!bulb.garlic.com!not-for-mail cp/40 did it back circa 65/66 on 360m40. cp/67 did it on 360/67 (circa 67-73 or so). 370 could do it easily. on the 360 & 370s ... there was a single instruction that could both change privilege status as well as addressing mode. It allowed virtualization kernels that were totally hidden from the stuff being virtualized. Later generations after the 360/370 got a lot more complex with their privilege modes ... and it was no longer possible to switch both privilege mode as well as addressing mode in a single instruction. For these later architectures explicit hardware support for virtualization was added (previously virtualization software support could be crafted built with standard machine architecture). Current generation in the 360/370 lineage have added so much virtualization hardware support that it is possible to do it totally within what appears to be purely hardware .... i.e. LPAR or logical partitioning support (i.e. possibly a majority of the current installations have systems configured as two or more "virtual" systems using LPAR support ... representing possibly the majority of commercial dataprocessing that occurs today). -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: alt.folklore.computers Subject: Re: Why can't more CPUs virtualize themselves? References: <6uoh41$9se$1@news3.infoave.net> <6uoouu$f9q$1@flood.weeg.uiowa.edu> Date: 28 Sep 1998 15:14:30 -0700 Message-ID: Organization: Brouhaha Computer Mercenary Services Lines: 33 X-Newsreader: Gnus v5.5/Emacs 20.2 NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 28 Sep 1998 14:15:17 -0800, ruckus.brouhaha.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.wli.net!su-news-hub1.bbnplanet.com!su-news-feed4.bbnplanet.com!news.bbnplanet.com!enews.sgi.com!news.sgi.com!news.spies.com!ruckus.brouhaha.com ted@ags.ga.erg.sri.com.foo.bar.com wrote: > Does anyone know why CPUs that could virtualize themselves never really > caught on? jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > But they did catch on. The 370 could and can do it, and so can a PDP-8 > with the optional KM8 memory management unit. The PDP-11 with memory > management can certainly do it, the VAX can do it, Are you certain that there is no way for a PDP-8 w/ KM8, PDP-11, or VAX program to detect that it is running in user mode? Remember that this capability, while not necessary for virtual memory, is critical for a virtual machine. For example, on the 68000 the instruction 'MOVE SR,Dn' is not priviledged, and allows the software to inspect the value of the user/supervisor flag. On the 68010 they made that instruction priviledged, and added the 'MOVE CCR,Dn' instruction which allows user mode software to inspect only the condition codes. Thus the 68010 (when coupled with a suitable MMU) is virtualizable, but the 68000 is not. > and so can the 80x86 so long as x>2. No, unfortunately the x86 *CANNOT* virtualize itself. The x86 for x>=3 has a virtual 8086 mode, but there are 386 instructions that can't be virtualized, mostly those relating to segment descriptors. This is why, for example, it is not possible to run unmodified Windows 95 in a Linux process. I keep hoping that the x86 cloners will add this capability, but they don't seem to care about it any more than Intel does. The Alpha can't do it either, at least when using standard PALcode, because the standard PALcode doesn't provide any way to trap the PALcode calls that might be made by the virtual machine. ###### From: jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.folklore.computers Subject: Re: Why can't more CPUs virtualize themselves? Date: 28 Sep 1998 19:44:30 GMT Organization: The University of Iowa Lines: 17 Message-ID: <6uoouu$f9q$1@flood.weeg.uiowa.edu> References: <6uoh41$9se$1@news3.infoave.net> NNTP-Posting-Host: pyrite.cs.uiowa.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!feed1.news.luth.se!luth.se!newspump.monmouth.com!newspeer.monmouth.com!nntp.msen.com!news.altair.com!NewsNG.Chicago.Qual.Net!news.uiowa.edu!not-for-mail From article <6uoh41$9se$1@news3.infoave.net>, by ted@ags.ga.erg.sri.com.foo.bar.com: > Does anyone know why CPUs that could virtualize themselves never really > caught on? But they did catch on. The 370 could and can do it, and so can a PDP-8 with the optional KM8 memory management unit. The PDP-11 with memory management can certainly do it, the VAX can do it, and so can the 80x86 so long as x>2. The question shouldn't be why the CPU's couldn't do this, rather, the question should be, why the OS environments on these machines rarely take advantage of this! Doug Jones jones@cs.uiowa.edu ###### From: karger@watson.ibm.com (Paul A. Karger) Newsgroups: alt.folklore.computers Subject: Re: Why can't more CPUs virtualize themselves? Date: 2 Oct 1998 03:51:19 GMT Organization: IBM T.J. Watson Research Center Message-ID: <6v1ijn$dhm$1@mdnews.btv.ibm.com> References: <6uoh41$9se$1@news3.infoave.net> <6uoouu$f9q$1@flood.weeg.uiowa.edu> NNTP-Posting-Host: watpub1.watson.ibm.com X-Newsreader: xrn 8.01 Originator: karger@watson.ibm.com Lines: 76 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!woodstock.news.demon.net!demon!news.idt.net!netnews.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!nyd.news.ans.net!nyd.news.ans.net!abq.news.ans.net!newsfeeds.ans.net!abq.news.ans.net!news.chips.ibm.com!mdnews.btv.ibm.com!karger In article , Eric Smith writes: |> ted@ags.ga.erg.sri.com.foo.bar.com wrote: |> > Does anyone know why CPUs that could virtualize themselves never really |> > caught on? |> |> jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: |> > But they did catch on. The 370 could and can do it, and so can a PDP-8 |> > with the optional KM8 memory management unit. The PDP-11 with memory |> > management can certainly do it, the VAX can do it, |> |> Are you certain that there is no way for a PDP-8 w/ KM8, PDP-11, or |> VAX program to detect that it is running in user mode? Remember that this |> capability, while not necessary for virtual memory, is critical for a virtual |> machine. An unmodified VAX program could detect what processor state it was in by using either a MOVPSL instruction or (with more difficulty) the PROBEx instructions. However, the VAX architecture was modified to support virtualization as described in the following two papers: Karger, et. al., A Retrospective on the VAX VMM Security Kernel, IEEE Transactions on Software Engineering, Vol. 17, No. 11, November 1991, pp. 1147-1165. Hall and Robinson, Virtualizing the VAX Architecture, Proc. 18th Annual Symposium on Computer Architecture, May 1991, pp. 380-389. Gerry Popek did a PDP-11 VMM at UCLA in the mid-1970s. The PDP-11 architecture needed some modifications, described in the following paper: Popek and Kline, The PDP-11 Virtual Machine Architecture: A Case Study. Proceedings of the Fifth Symposium on Operating Systems Principles, Operating Systems Review, Vol. 9, No. 5, November 1975, pp. 97-105. |> |> For example, on the 68000 the instruction 'MOVE SR,Dn' is not priviledged, |> and allows the software to inspect the value of the user/supervisor flag. On |> the 68010 they made that instruction priviledged, and added the 'MOVE CCR,Dn' |> instruction which allows user mode software to inspect only the condition |> codes. Thus the 68010 (when coupled with a suitable MMU) is virtualizable, |> but the 68000 is not. |> |> > and so can the 80x86 so long as x>2. |> |> No, unfortunately the x86 *CANNOT* virtualize itself. The x86 for x>=3 has a |> virtual 8086 mode, but there are 386 instructions that can't be virtualized, |> mostly those relating to segment descriptors. This is why, for example, it is |> not possible to run unmodified Windows 95 in a Linux process. I keep hoping |> that the x86 cloners will add this capability, but they don't seem to care |> about it any more than Intel does. |> |> The Alpha can't do it either, at least when using standard PALcode, because |> the standard PALcode doesn't provide any way to trap the PALcode calls |> that might be made by the virtual machine. As a result of the work on the virtualizing the VAX, the Alpha architecture was carefully designed to be virtualizable by modifying the PALcode. All privileged or sensitive instructions are required to be implemented by PALcode, and PALcode is required to be replaceable. You don't want the virtualization code in all PALcode, because it would introduce extra overhead. Rather, if you want to run a virtual machine monitor on a particular Alpha CPU, you load modified PALcode to interact with the VMM software. Unfortunately, Digital cancelled the entire VMM project, before an Alpha VMM could be built. Initial indications were that the performance cost of an Alpha VMM would have been much lower than the VAX VMM, which were already quite low. This was because PALcode would allow tailoring exactly what you need in each privileged or sensitive instruction, without affecting anything else in the processor's speed-critical paths. Note - sensitive instructions are defined in Goldberg's classic PhD thesis - required reading for anyone trying to build a virtual machine monitor: Goldberg, Robert P. Architecural Principles for Virtual Computer Systems, PhD thesis, Harvard University, published as ESD-TR-73-105, HQ Electronic Systems Division, L. G. Hanscom Field, Bedford, MA, February 1973.