questions about Hyperprivileged layer
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!
[502 byte] By [
Doriaa] at [2007-11-27 2:05:18]
# 1
Someone else may be able to provide a more accurate or more detailed response, but I'll take an initial crack at it.
> 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.
Keep in mind that "BIOS" is a term largely used in x86/x64-based systems. There is no entity called a "BIOS" in a SPARC-based system.The Hypervisor probably covers most of the low-level portions of that functionality, though. When Solaris is running on top of the Hypervisor, additional booting functionality is in the Open Boot PROM (OBP) code, which may overlap with some of the boot code in x86/x64 BIOS firmware.
> When the system takes a cold reset, what does the
> Hyperprivileged layer do?
I'm not a Hypervisor expert, but can tell you that a "cold" reset (e.g. a power-on reset) causes a lot of processor state to be initialized in hardware, then execution begins -- it begins in hyperprivileged mode, at a specified start address in the hyperprivileged trap table, in one strand (virtual processor).Hypervisor software can unpark other strands (virtual processors), allowing execution to begin on them. The Hypervisor also builds a device tree that can be passed on to guest operating systems that may boot on top of it.
> 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?
Yes, all CMT (Chip Multi-Threading) control is purely hyperpriivileged -- a guest operating system cannot park/unpark or enable/disable virtual processors itself, only the Hypervisor can.CMT control is all performed through accesses to CMT control registers, which can only be accessed by software running at the hyperprivilegedm戧衑l (that is, Hypervisor software).
# 2
dweaver,thank you very much!
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?
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? What the Hypervisor does is totally transparent to a guest operating system. The OS is in charge of the process scheduling, but how it realizes is the Hypervisor's business. The OS has no idear about which strand is under using.The Hypervisor locates a thread to a certain strand. Is it right?
Thank you!
Message was edited by:
Doria
Message was edited by: Doria
Doria
# 3
I have found some answers at this website:
http://www.itworld.com/AppDev/616/UIR951001openboot/
Google first, then ask!
Now in my point of view, I consider Hyperprivileged layer is higher than the OBP layer. If there are more than one OS operating on the SUN hardware, Hyperprivileged layer can manage them.
If there is only one OS running on a CMT system (not SUN's), can I throw the Hyperprivileged layer off? Or there must be a kind of Hyperprivileged layer in a CMT system?
# 4
> 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.
# 5
> I have found some answers at this website:
> http://www.itworld.com/AppDev/616/UIR951001openboot/
The answers there are with respect to older SPARC systems booting Solaris on top of OpenBoot, before there was a hyperprivileged mode.It's still accurate AFAIK for those systems, but doesn't directly apply to hyperprivilege-enabled processors such as UltraSPARC T1 (and beyond).
> ...I consider Hyperprivileged layer is higher than the OBP layer. If there are more
> than one OS operating on the SUN hardware, Hyperprivileged layer can manage them.
No, it's the other way around.Hypervisor "owns" the bare hardware.A guest OS (it's a guest of the Hypervisor) canonly play with what the Hypervisor has given it permission to play with -- typically via calls through the Hypervisor API.
Now when a (hyperprivileged-enabled) machine boots, it boots into the Hypervisor.OpenBoot and Solaris reside in a guest partition on top of Hypervisor.
> If there is only one OS running on a CMT system (not SUN's), can I throw the Hyperprivileged layer off?
> Or there must be a kind of Hyperprivileged layer in a CMT system?
You ask about two scenarios here ...
(1) If it's a Sun CMT system, then yes, you can run a single OS on the bare hardware, controlling the whole CMT system. You would need to burn the appropriate hyperprivileged firmware into the flash memory on the system board (replacing the current Hypervisor code), and you'd have to alter (port) your OS to directly control devices.However, it's much easier to just port an OS to run on top of Hypervisor, let Hypervisor handle all direct device interaction, and boot the OS requesting control of all threads on the machine (typical single-image-OS-on-SMP-system configuration)....However, when you said "throw the hyperprivileged layer off", no you can't quite do that.Some of the code (even if it's OS code) needs to run in hyperprivileged mode.
(2) if it's a non-Sun CMT system, there may or may not be the equivalent of a hyperprivileged layer on that processor. And if there is a hyperprivileged layer, the line between OS and Hypervisor may be drawn at a different level of abstraction (higher or lower) than Sun (carefully) chose. In any case, if you can change the firmware (BIOS, boot PROM, etc) and you change the OS to directly control the underlying hardware, then yes, I would think that you'd be able to boot one OS controlling all threads on the processor.
# 6
Dweaver: Thank you very much!!!
