Why settle for "privilege" when you can have "hyperprivilege"!
This "hypervisor" talk has always kind of rubbed me the wrong way. What happens when we want another level of indirection? Do I get a "megavisor"? A "superdupervisor"? I'm rooting for the "ubervisor." IBM actually found it necessary to construct such an ubervisor, to aid hypervisor development, and explicitly supported it in their hardware virtualization extensions to the s/370. I know it sounds like I'm making this up, but I'm not.
Anyway. Sun has released a draft of the hardware and software specs for their virtualization extensions. Check it out. From a technical point of view, it's interesting that they're treating the representation of guest privileged state as a collection of "hyperprivileged" registers, rather than fields in an in-memory, hardware-walked struct, as the x86 hardware assistance initiatives have done. The privileged register approach has the nice property of making nesting work somewhat more cleanly, but also has the unfortunate property of making accesses to guest state slower. (Assuming, of course, that getting at these "hyperprivileged" registers is slower than, say, a load or a store. Take anything I claim about sparc with a big grain of salt, because I, like everyone else, have not done real work on them since college.)
They seem to be taking an IBM-esque approach of viewing the hypervisor as a firmware extension, rather than a shrink-wrapped set of software. This was how virtualization worked back in the Popek and Goldberg era; vendors controlled the entire vertical stack from hardware up to the application. Since all layers of the hardware/software stack were fungible, changes in both hardware and software could be made to accomodate virtualization. Virtualization-motivated changes to the hardware (via VT and SVM) and software (the kids call it paravirtualization these days) are both back with a vengeance, though not because any one company controls the hardware software stack anymore. The hardware changes have been motivated by the popularity of third-party virtualization software, while the software changes have been made possible by the availability of freely modifiable, high quality operating systems like Linux. As with all things virtualization, everything old is new again, but for different reasons.
Anyway. Sun has released a draft of the hardware and software specs for their virtualization extensions. Check it out. From a technical point of view, it's interesting that they're treating the representation of guest privileged state as a collection of "hyperprivileged" registers, rather than fields in an in-memory, hardware-walked struct, as the x86 hardware assistance initiatives have done. The privileged register approach has the nice property of making nesting work somewhat more cleanly, but also has the unfortunate property of making accesses to guest state slower. (Assuming, of course, that getting at these "hyperprivileged" registers is slower than, say, a load or a store. Take anything I claim about sparc with a big grain of salt, because I, like everyone else, have not done real work on them since college.)
They seem to be taking an IBM-esque approach of viewing the hypervisor as a firmware extension, rather than a shrink-wrapped set of software. This was how virtualization worked back in the Popek and Goldberg era; vendors controlled the entire vertical stack from hardware up to the application. Since all layers of the hardware/software stack were fungible, changes in both hardware and software could be made to accomodate virtualization. Virtualization-motivated changes to the hardware (via VT and SVM) and software (the kids call it paravirtualization these days) are both back with a vengeance, though not because any one company controls the hardware software stack anymore. The hardware changes have been motivated by the popularity of third-party virtualization software, while the software changes have been made possible by the availability of freely modifiable, high quality operating systems like Linux. As with all things virtualization, everything old is new again, but for different reasons.
posted by Keith Adams at 3:40 PM
0 comments
