What was the first microprocessor to support full virtualization?

Question

Virtual memory, which allows an operating system to run several machine code programs isolated from each other, came to the desktop during the eighties. But full virtualization, which lets the hypervisor run several operating systems isolated from each other on the same machine, as I understand it came quite a bit later, e.g. the 386 for some reason was not able to run multiple virtual 386s. (Short of doing software emulation, which has a hefty performance penalty.)

What was the first microprocessor that could virtualize itself to support hypervisors?

(The intent of specifying a microprocessor is to omit systems like the IBM 360, which usually turn out to have done these things a decade or two earlier. I would actually also be interested in which mainframes supported full virtualization, but it's not the focus of this question.)

Answer 1

Full, hardware-assisted virtualisation, with the intention of supporting hypervisors running operating systems without requiring para-virtualisation, was added to micro-processors relatively recently. (Many RISC-style architectures were virtualisable following Popek and Goldberg’s criteria, and were used in high-end partitionable systems, but with external support.)

The main architectures which support full hardware-assisted virtualisation are the following:

• SPARC, starting with the sun4v architecture, first implemented in the UltraSPARC T1 in 2005;
• Power, starting with ISA 2.06 in 2009, implemented for example in POWER7 (earlier Power ISAs supported virtualisation, with a specific hypervisor mode, but 2.06 introduced significant virtualisation acceleration features);
• Itanium, starting with Poulson in 2012;
• x86, starting with Intel VT-x in 2005 and AMD-V in 2006, with additional features in later architectures such as VT-d and extended page tables in 2008, unrestricted guests in 2010, and VMCS shadowing in 2013.

So arguably the first micro-processor with full virtualisation was the UltraSPARC in 2005 — I’ll ignore VT-x on its own since it wasn’t all that useful in practice for real-world implementations.

An exact answer depends on the exact definition of full virtualisation; earlier CPUs (in particular, MIPS and PowerPCs) had good virtualisation support with the help of software emulation. In the early 2000s, as CPU speeds accelerated markedly, the performance cost of software virtualisation dropped, and virtualisation software became usable without hardware assistance in many scenarios. If we consider that virtualisation should cover the whole CPU, hardware-assisted virtualisation accelerators included, then I think the answer is Haswell in 2013 since that’s the first architecture (as far as I’m aware) to support full hardware-assisted nested hypervisors.

John Fisher-Ogden’s 2006 paper on Hardware Support for Efficient Virtualization provides a good introduction to virtualisation in IBM’s mainframes, and the architectural constraints in the x86 architecture, along with potential solutions.

Answer 2

The Popek and Goldberg virtualisation requirements are usually dug out for discussions of this kind, but it is more of a quick rule-of-thumb and it turns out that doing virtualisation well requires a more than their rules, and with ingenuity one can get away with less. Ultimately, there is no single answer because it's a case of evolution with it being subjective as to whether a particular combination of hardware and software counts.

The first time I saw virtualisation work on a microprocessor in a satisfactory manner was VMWare back in 1998. I was running it on a creaky old Pentium, which does not satisfy Popek and Goldberg. The particular innovation here was advances in compiler technology that made it plausible to transform arbitrary x86 code into a safe subset which could be run natively without breaking out of the sandbox.

This wheeze could therefore theoretically be used on any microprocessor with enough resources to run a suitable binary-to-binary compiler and still have enough left over to do useful work. The 68020 (1984) and 80386 (1985) would definitely count, the 68000 (1979) and 80286 (February 1982) might count, and definitely not for our 8-bit favourites. But this would require a time machine to send 1990s computer science papers back 15 years.

What about other off-the-wall approaches? As I recall, the Sun-1 workstation (May 1982) ran two 68000s executing the same instruction stream, one of which ran a critical period behind the other such that when a state-losing bus exception occurred in the first, the paging hardware could recover the state from the second which had not yet executed the problematic code. Wikipedia does not confirm this, so I may be misremembering.

If your definition is merely that the CPU be sufficiently-capable of doing memory protection and virtualisation within tight constraints which still allow useful work to be done, the 80286 might still be in the running, and slightly predates the Sun-1. The 80286 is just about powerful to run protected-mode operating systems such as Unix which present a virtual machine for userspace processes to run in, however this does not correspond to any real bare metal CPU and cannot recursively run another operating system requiring privileged instructions.

So what about systems with the kind of hardware support for virtualisation that Popek and Goldberg envisaged? A 68010 (1982) with 68451 MMU counts. The now-forgotten NS320xx (1982) would likely also count, but Wikipedia claims it came out after the 68010.

So the 68010+68451 combination is my personal choice of best answer to this question.

Answer 3

What does full virtualization mean in this context?

I guess a more general approach may be helpful.

First off, as soon as virtualization leaves the topic of the (core) CPU, anything becomes machine and implementation specific - so it's not only relying on the CPU itself. Further, even such a virtualization does usually need an hypervisor, another OS, providing real world services to these - and being able to emulate next to all external resources. More often than not, such a 'Guest OS' does provide hypervisor specific drivers in addition, avoiding extreme performance impacts.

At the heart it's about the 'picture' a 'bare metal' (*1) application gets of the machine it's running on one side, and what kind of hardware access the guest OS does expect.

Despite facing the danger promised, I would like to cite the /360 as a more simple example to display this fact. Already from the start I/O was quite formalized as an interface to an IO processor (*2). There was a limited set on instructions to start an I/O operation, check for status and cancel them if necessary, but no other way to communicate with the outside. These high level structures made it easy to virtualize I/O, after memory and CPU were done (*3)

For micros (and minis) the task was a way more complex one as their low level I/O. Low level was not a huge pile of separate instructions manipulation I/O addresses that needed to be interpreted in a coherent way.

With all that said and for 8 bit microprocessors I'd give a 6809 in a system with a 6829 MMU (and maybe a 6828 PIC (Priority Interrupt Controller)) a head-start in 1978 (*4). Depending on hardware and OS structure this would work out fine.

In reality the issue is as so often not about technology, but the need for solutions. With micros there was no use case. Where mainframes focused, during the 80s and 90s, quite a lot on machine virtualization to consolidate installations, micros spread just as they were. 'Lesser' ways of virtualization did provide everything to satisfy the need for executing parallel applications and services in a sufficiently separated way. Much like with mainframes before, adding more CPUs was more important than to make virtual machines share a real one.

During the 90s micros had taken on more and more roles as servers, spread out in companies, 'infecting' every corner. This resulted in high pressure to consolidate. Servers where moved to computing centres and migrated into rack mount machines. While many of these applications did need their custom environment, they did use only small portions of a machine's resources. At the same time the early 2000s brought new highly partitioned applications with services in prior unimaginable numbers for high throughput web servers, search engines and alike. In combination this created a surge for virtualization, a need CPU manufacturer satisfied with new models. First with server processors, where the use case originated, in the long run for everyone.

The rest is history and I'd rather shut up and point to Stephen Kitt's detailed answer.

... Aaaargh ... I can't.

The 80386 did offer a 8086 VM mode that enabled hosting of multiple instances of its predecessor. The important part here is that it not only restricted access to 'unknown' register, and offered separate memory spaces but also allowed to trap access to (marked) memory and instructions like IN and OUT. As a result a 386 hypervisor could run multiple virtual 8086 instances, alas not emulating the PC running on, but any 8086 machine.

Something not uncommon in other families of CPUs, where new models not only offered (some) compatibility, but also full emulation - as it was called back then. Constructions like a /370 running a virtual /360 running a virtual 1401 where not unheard of.

---

*1 - Term chosen in lieu of any better. Meaning is that an application that can act as if running on the same (or similar) machine as if there was no virtualization.

*2 - Much like Intel envisioned for the x86 family with the 8089 I/O-Processor

*3 - Another great example how benefiting clean abstraction layers are in the long run.

*4 - IIRC it may as well have worked already with 6800+6829, but I'm unsure abut the introduction date of the 6829. It was available when the 6809 was introduced.