Questions about Hyperprivileged layer

Question

I am a college student, who is interested in the OPENSPARC architecture. I have been reading the UA2005-current-draft-HP-EXT.pdf document recently, but I still puzzled about the relationship between the Hyperprivileged layer and the BIOS. When the system takes a cold reset, what does the Hyperprivileged layer do? Take SPARC 2005 for example. After one strand in the unparked mode, how to unpark the other strands? Does this have anything to do with the Hyperprivileged layer?
Thank you!

Answer 1

> I still have several questions.
The first one is about the OBP. What is OBP? Where can I get it?
Is it part of Solaris' codes, or any OS has its own OBP?
OBP (Open Boot PROM) is available in open-source form, as part of the OpenSPARC T1 download -- see http://opensparc-t1.sunsource.net/download_sw.html .
I won't pretend to be an OBP expert, but am 90% certain that OS's other than Solaris can boot on top of OBP.
> Secondly, you said "all CMT (Chip Multi-Threading) control is purely hyperpriivileged". Did you mean
that all CMT control, not only SUN's architecture, is purely hyperprivileged?
First, note that Sun was the first with broad-ranging, extensible CMT control. When Sun announced the 32-thread T1, the most anyone else could muster was a dual-thread chip. No other vendor has needed to control more than 2 threads on a single die. Others are now up to 4 single-thread cores per die, and Sun is going to ship 64-thread chips soon. Pardon what may read as "Sun flag-waving" ;-) , but as the saying goes, "Necessity is the Mother of Invention" -- effective, scalable control of highly-threaded processors was a necessity at Sun much earlier than elsewhere.
There may be many philosophies about control of CMT threads. Sun decided that it should be controlled only at the hyperprivileged level -- otherwise, a guest operating system would have the privileges to shut down threads controlled by another guest OS on the same processor chip.
...Note that the older UltraSPARC IV and IV+ processors (which are 2-threaded) were the first multi-threaded (dual-core, in this case) processors developed at Sun. That development occurred prior to the advent of hyperprivileged mode, therefore CMT control on those processors is privileged, not hyperprivileged. Without Hypervisor, the US IV and IV+ processors can/should run the same OS (a trustworthy one!) on both threads, since either OS can corrupt the other if it's buggy or malicious (neither of which is an issue on UltraSPARC T1 with Hypervisor -- 32 different OSs could run simultaneously and no OS could corrupt another)
> What the Hypervisor does is totally transparent to a guest operating system.
Yes, in the same sense that what an OS does "under the hood" is transparent to a software application. An OS requests service via a Hypervisor call (trap to hyperprivileged mode), jjust application requests service via a system call (trap to privileged mode). Technically, "what" the Hypervisor does is known to the OS, but the OS has no idea "how" Hypervisor does it.
> The OS is in charge of the process scheduling, but how it realizes is the Hypervisor's business.
The OS has no idea about which strand is under using. The Hypervisor locates a thread to a certain strand. Is it right?
Yes, the OS can make inqueries to Hypervisor about what resources are available for it (the OS) to manage. The Hypervisor would typically give the OS one or more threads (hardware strands or virtual processors) to manage.