How does OpenSPARC translate Virtual Address to Physical Address or Vice V

> ... when I read the source code of the bw_r_tlb of OpenSPARC抯 MMU, I am puzzled. I am not clear how is

> the page address system of OpenSPARC implement. Will you offer me some hints about it ? And are

> there any documents about it?

There sure is documentation!

When you say that you're looking at "bw_r_tlb", I assume you're looking at the lowest-level bits of the implmentation -- the pure RTL (Verilog) code.To understand the translation, it is helpful to step back a couple of steps for a description of the "big picture".

A quick overview is that there are three levels of addressing: Virtual, Real, and Physical. Nonprivileged (application) software only sees Virtual addresses.Privileged (operating system) software sees Virtual and Physical addresses (and sets up the VA-->RA translations).Hyperprivileged software sees all three levels of addressing (and manages all translations to physical addresses (PAs)).This is diagrammed in Figure 14-1 of the architecture document mentioned in the next paragraph and explained in detail in the accompanying text.

I recommend that you first take a look at Chapter 14, Memory Management, of the UltraSPARC Architecture 2005 Specification (http://opensparc.info/cgi-bin/goto.php?w=http://opensparc-t1.sunsource.net/spe cs/UA2005-current-draft-HP-EXT.pdf), which can be found on this page of the OpenSPARC.net web site: http://opensparc-t1.sunsource.net/index.html .

There are a few additional OpenSPARC T1-specific details in Chapter 13, Memory Management Unit, of the UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification (http://opensparc.info/cgi-bin/goto.php?w=http://opensparc-t1.sunsource.net/spe cs/UST1-UASuppl-current-draft-HP-EXT.pdf), found on the same web page as the above document.

If those don't answer your questions, please post back to this forum!

= Dave

dweaver at 2007-7-7 12:10:47 >

The software that runs in hyperprivileged mode is generally terms "Hypervisor" software (similar to privileged-mode software being called "Supervisor" software).

Hypervisor software, as Sun designed it, is a thin layer of software that runs on top of the bare hardware. It "owns" physical memory, MMU hardware, and devices, and provides an abstracted set of service calls (the "Hypervisor API") to privileged software (guest operating systems) ... much as a privileged operating system provides an API for system calls that application software can use.

The use of Hypervisor service calls for a guest operating system to communicate with the Hypervisor allow the Hypervisor to make it appear to each guest OS that it (the privileged OS) is the only OS running on the machine.That is, Hypervisor presents a completely virtualized, isolated machine to each guest OS.Multiple guest OSs can run simultaneously on top of Hypervisor, with a certain hardware resources (threads of execution, physical memory, etc) assigned to each. Guest OSs are totally isolated from each other; none can touch another one's resources, none can corrupt, "spy on", or bring down another OS. Each OS believes that it's running on its own hardware containing whatever resources were assigned by the Hypervisor.

In short, Hypervisor provides complete and iron-clad virtualization service.As I understand it, it is similar in intent to Xen or Virtual Iron.

The Hypervisor API specification can be downloaded from a link near the bottom of page http://opensparc-t1.sunsource.net/index.html .

The full source code to the Hypervisor itself can be downloaded from the "OpenSPARC T1 Download for Architecture and Performance Modeling" page, at http://opensparc-t1.sunsource.net/download_sw.html .

dweaver at 2007-7-7 12:10:47 >

> I have downloaded the source code oflinux-2.6.17.9 version. In the arch directory of linux-2.6.17.9, I

> find the Hypervisor API (such as sun4v_intr_setstate, sun4v_intr_gettarget) has been

> integrated with Linux kernel. In other words, it is implemented in Linux kernel. All the time, I think

> Hypervisor API is an independent layer which provides an easy way to switch among all kinds of OS. But now,

> I find it is a part of Linux. If so, what a role does Hypervisor API take? Why do we name it Hypervisor API

> rather than a part of Linux? It do puzzle me, am I wrong?

The Hypervisor API ("application programming interface") is fully described in the UltraSPARC T1 Hypervisor API Specification, which is downloadable from page http://opensparc-t1.sunsource.net/index.html .

As a brief digression ... the term "Hypervisor API" has always seemed a bit oxymoronic to me -- given the historic equivalency of "application" to "nonprivileged". After all, isn't it more of an "SPI" (supervisor programming interface) because it services privileged supervisor (operating system) software, not nonprivileged (application) software? But if you think of a guest OS as an "application" (in the general sense of the word) supported by the Hypervisor, then "Hypervisor API" makes some sense.

Now, regarding Hypervisor API and Linux.If you read the UltraSPARC T1 Hypervisor API Specification, you'll find that Hypervisor API calls are defined (appropriately enough) in terms of native SPARC assembly language.I haven't looked at the Linux source code, but I'd bet a considerable sum of money that the Linux sun4v_intr_gettarget() function is a C-language wrapper around a SPARC assemly-language routine that sets up arguments, performs a trap to the Hypervisor intr_gettarget function, and returns the result(s) to the caller.

In any case, all actual Hypervisor code is fully implemented in the Hypervisor, not in Linux or Solaris or FreeBSD or Wind River Linux or any other OS running on top of the Hypervisor.Each OS may implement some "wrapper" code around Hypervisor calls, but no actual Hypervisor functionality actually resides in a guest OS. In fact, it can't reside in a guest OS because it must run in hyperprivileged mode and guest operating systems run in "merely" Privileged mode.

dweaver at 2007-7-7 12:10:47 >

On 12/14/06 09:13, Shrenik Mehta (Frontend Technologies & OpenSPARC) wrote:

> It would be good to add the definition of Hypervisor in the wikipedia.

It's already there.But I just added more mentions of Sun's Hypervisor

to it.

[David.Weaver.vcf]

To unsubscribe, e-mail: general-unsubscribe@opensparc.sunsource.net

For additional commands, e-mail: general-help@opensparc.sunsource.net

dweaver at 2007-7-7 12:10:47 >

> 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.

First, keep in mind that the term "BIOS" is mostly used in the x86 world, which makes it difficult to directly answer your question.There is no entity actually called a "BIOS" on a SPARC system. That said, I'll try my best to answer the question(s) I think you're asking...

Let's start out and assume that "BIOS" equates to the more general term "firmware".

On older SPARC systems (before Hypervisor), the OBP (Open Boot PROM) code performed a similar function to BIOS on x86 systems. The system booted into OBP code, which was located in firmware (nonvolatile memory, such as PROM or flash) on the motherboard. OBP performed low-level processor testing/set-up/iniitialization, probed for devices, formed a device tree, etc, etc. Finally, it loaded the operating system from the boot device and began OS execution.

Nowadays, on Hypervisor-enabled SPARC systems, hyperprivileged-mode software ("the Hypervisor") is firmware that ships with the processor (not with an OS).When the processor powers on (or performs any type of hard reset), it is set into hyperprivileged mode, vectors to a fixed location in physical memory, and begins fetching instructions there (the initial entry point into the Hypervisor).The Hypervisor performs low-level processor self-test/set-up/iniitialization, probes for devices, forms a device tree, etc, etc.It then enables the other strands (virtual processors) on the chip, and finally boots one or more privileged-mode operating systems on those strands.[How it decides which OSs to boot on which strands, or which resources to provide to each OS, I personally don't know -- but the Hypervisor knows ;-).]

The Hypervisor owns the hardware (devices).An OS has to make a request to Hypervisor (via a trap to Hypervisor) to access a real (or virtual) device -- that includes the MMU.

Note that the Hypervisor launching operating systems is very much like operating systems launching applications.And operating systems making Hypervisor service calls (following the Hypervisor API) is exactly like application software making supervisor (OS) service calls, following the operating system's system-call API.

> Take SPARC 2005 for example.

I assume this means a processor that implements the UltraSPARC Architecture 2005 (such as UltraSPARC T1/ OpenSPARC T1)

> After one strand in the unparked mode, how to unpark the other strands?

When the processor powers on, only one strand is inititally running.When it's ready to unpark the other 31 strands, it does so by accessing a set of CMT control registers. They are accessed via Load and Store instructions to Alternate address space, where the alternate address space selected in the instruction is the ASI that refers to the CMT control registers.Which control register is accessed is selected via the virtual address provided in the Load or Store instruction.

If you hunger for all the gory details, refer to the CMT chapter in (the hyperprivileged version of) the UltraSPARC Architecture 2005 specification.

> Does this have anything to do with the Hyperprivileged layer?

Yes, in that all the CMT control registers are hyperprivileged registers, only visible/accessible to hyperprivileged software -- that is, the Hypervisor. It owns them.

dweaver at 2007-7-7 12:10:48 >