Abstract:
To virtualize a system without having to incorporate a special mechanism into software and with increases in overhead suppressed, by controlling memory accesses made by processors using hardware. 
     A device controls memory accesses made by processors and includes multiple address tables that correspond to multiple operating systems (OSs) run by the processors and each translate the logical address of the destination of a memory access made by one of the processors into a physical address in a memory or memory; and a table selection unit that, when one of the processors makes a memory access, obtains identification information of the processor and selects an address table corresponding to an OS run by the processor identified by the identification information from among the address tables as an address table that performs address translation with respect to the memory access.

Description:
FIELD OF THE INVENTION 
       [0001]    Embodiments of the present invention relate to a device that virtualizes a system by controlling memory accesses and a computer including the device. 
       BACKGROUND 
       [0002]    In computer architecture, it has been practiced to create a software operating environment using virtual hardware obtained by virtualizing processors, memory, and the like, so that multiple software programs such as operating systems (OSs) can be run. This type of virtualization technology has been achieved by one of a method called host OS type and a method called hypervisor type. (For example, see Patent Literature 1) 
         [0003]      FIG. 8  is a diagram showing the concept of a host OS-type virtualization method. 
         [0004]    As shown in  FIG. 8 , a single host OS  811  runs on hardware  810  in a host OS-type system. On the host OS  811 , its tasks  812  are executed and a guest OS  814  is run through a virtual machine monitor  813 . On the guest OS  814 , its tasks  815  are executed. That is, in the host OS-type system, one of the installed OSs acts as the host OS  811  and provides an operating environment for the other OS (guest OS  814 ). While the single guest OS  814  is shown in the diagram, multiple guest OSs  814  may be installed together with corresponding virtual machine monitors  813 . 
         [0005]      FIG. 9  is a diagram showing the concept of a hypervisor-type virtualization method. 
         [0006]    As shown in  FIG. 9 , a hypervisor  911  runs on hardware  910  in a hypervisor-type system. Multiple guest systems (OSs and tasks executed on the OSs)  912  run on the hypervisor  911 . 
         [0007]    A function for virtualizing a system has been provided by software thus far. That is, virtual hardware for running a guest OS has been achieved using the above-mentioned host OS or hypervisor function. For this reason, there has been a need to incorporate a special mechanism for virtualization into installed software. 
         [0008]    For example, in host OS-type systems, the host OS runs even when the guest OS runs. This disadvantageously increases the load imposed on the hardware, increasing the overhead. Further, special software for running the guest OS, such as a virtual machine monitor, is needed. 
         [0009]    In hypervisor-type systems, a hypervisor must be formed in a manner corresponding to installed hardware and an OS that runs on the hypervisor. For this reason, when the configuration of the hardware or the type of the OS used is changed, a hypervisor corresponding to the changed hardware or OS must be created. This makes it difficult to construct a flexible system, whose configuration is easily changed. 
         [0010]    Further, hypervisor-type systems are classified into so-called para-virtualization type and full-virtualization type. In para-virtualization type, the guest OS must be adapted to the hypervisor. That is, the guest OS must be designed or modified so that it can use a virtual environment provided by the hypervisor. 
         [0011]    On the other hand, in full-virtualization type, there is no need to make a modification or the like to the guest OS. However, the hypervisor must support the operation of the guest OS in the virtual environment, thereby disadvantageously increasing the overhead as in host OS-type. 
         [0012]    Accordingly, it is an object of the present invention to virtualize a system without having to incorporate a special mechanism into software and with increases in overhead suppressed, by controlling memory accesses made by processors using hardware. 
         [0013]    To accomplish the above-mentioned object, embodiments herein disclose a device to control memory accesses made by multiple processors. The device includes multiple address translation units that correspond to multiple operating systems (OSs) run by the processors and each translate the logical address of the destination of a memory access made by one of the processors into a physical address in a memory; and a selection unit that, when one of the processors makes an memory access, obtains identification information of the processor and selects an address translation unit corresponding to an OS run by the processor identified by the identification information from among the address translation units as an address translation unit that performs address translation with respect to the memory access. 
         [0014]    More specifically, each of the address translation units receives an access instruction outputted by the processor and translates a logical address specified in the access instruction into a physical address in a memory area of the memory, the memory area corresponding to an OS run by the processor. 
         [0015]    More preferably, each address translation unit receives an instruction for access to a boot memory, the instruction being made by the processor, the boot memory storing boot programs for booting the OSs and translates a logical address specified in the access instruction into a physical address in the boot memory. 
         [0016]    Preferably, the address translation units are each composed of programmable logic and a register. 
         [0017]    The selection unit preferably includes a multiplexer that receives address signals representing addresses translated by the address translation units and selectively outputs one of the address signals to the memory; and a switch that changes the address signal to be outputted by the multiplexer in accordance with the identification information. 
         [0018]    Another device is provided that controls memory accesses made by multiple processors. The device includes multiple address translation units that correspond to multiple OSs run by the processors and each receive an access instruction outputted by one of the processors, translate a logical address specified in the access instruction into a physical address in a memory area of a memory, the memory area corresponding to an OS run by the processor, receive an instruction for access to a boot memory, the instruction being made by the processor, the boot memory storing boot programs for booting the OSs, and translates a logical address specified in the access instruction into a physical address in the boot memory; and a selection unit that, when one of the processors outputs an access instruction, obtains identification information of the processor and selects an address translation unit corresponding to an OS run by the processor identified by the identification information from among the address translation units as an address translation unit that performs address translation with respect to the access instruction. 
         [0019]    The present invention also provides a computer having multiple operating systems (OSs) installed therein. The computer includes multiple processors; a memory; and an address translation device that, when one of the processors makes a memory access, obtains identification information of the processor and translates the logical address of the destination of the memory access made by the processor into a physical address in a memory area of a memory, the memory area corresponding to an OS run by the processor identified by the identification information. 
         [0020]    It is possible to virtualize a system without having to incorporate a special mechanism into software and with increases in overhead suppressed, by controlling memory accesses made by processors using hardware. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0021]      FIG. 1  is a diagram showing the concept of system virtualization according to an embodiment of the present invention. 
           [0022]      FIG. 2  is a diagram showing an example hardware configuration of a virtualization system according to this embodiment. 
           [0023]      FIG. 3  is a diagram showing a virtualization technique using a virtualization device according to this embodiment. 
           [0024]      FIG. 4  is a diagram showing an example function configuration of the virtualization device according to this embodiment. 
           [0025]      FIG. 5  shows the memory maps of OSs, the assignment of the memory space to a system memory in each OS, and the assignment of the boot area of a boot memory in each OS in an implementation example. 
           [0026]      FIG. 6  is a diagram showing the configuration of the implementation example of the virtualization system according to this embodiment. 
           [0027]      FIG. 7  shows a state in which settings are made for the virtualization device in the implementation example of the virtualization system shown in  FIG. 6 . 
           [0028]      FIG. 8  is a diagram showing the concept of a host OS-type virtualization method. 
           [0029]      FIG. 9  is a diagram showing the concept of a hypervisor-type virtualization method. 
       
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0030]    Hereafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings. 
         [0031]      FIG. 1  is a diagram showing the concept of system virtualization according to this embodiment. 
         [0032]    As shown in  FIG. 1 , a virtualization system according to this embodiment includes processors (processor cores)  10  and a virtualization device  20  as hardware. Sets of software (OS and application)  100  are run by the processors  10  through the virtualization device  20 . That is, according to this embodiment, each OS directly runs on the hardware without through a hypervisor or host OS. 
         [0033]    The virtualization device  20  mainly controls memory accesses made by the processors  10 . That is, the virtualization device  20  provides different address spaces for the OSs. Under the control of the virtualization device  20 , the OSs access the different address spaces while using the common physical memory. In this way, a virtual environment according to this embodiment is created. The configuration and functions of the virtualization device  20  will be described specifically later. 
         [0034]      FIG. 2  is a diagram showing an example hardware configuration of the virtualization system according to this embodiment. 
         [0035]    In  FIG. 2 , the virtualization device  20  is connected to a first local bus  51  and a second local bus  52 . Connected to the first local bus  51  are the processors  10  and an eDRAM (Embedded DRAM)  12 . Also connected to the first local bus  51  is a peripheral device (Peripheral Island Node)  13  and a chip interlink  14 . While the multiple (unspecified number of) processors  10  are shown in  FIG. 2 , systems according to this embodiment may include one or more processors  10  or may include a multi-core processor including multiple processor cores. 
         [0036]    Connected to the second local bus  52  is a boot memory controller  31  and a system memory controller  32 . The boot memory controller  31  controls a read only memory (ROM) serving as a boot memory  41 , while the system memory controller  32  controls a dynamic random access memory (DRAM) serving as a system memory  42 . Also connected to the second local bus  52  is an eDRAM  33 . 
         [0037]    Since the system is configured as described above, the processors  10  and an external device (not shown) connected to the system through the peripheral device  13  and the chip interlink  14  access the boot memory  41  and the system memory  42  through the virtualization device  20 . 
         [0038]    As shown in  FIG. 2 , each processor  10  is connected to the first local bus  51  via a decoder  11 . When a processor  10  makes a memory access through the virtualization device  20 , a decoder  11  connected to the processor  10  sends to the virtualization device  20  unique information for identifying the processor  10  (processor ID or the like) and information for identifying the process (process ID or the like) as a control signal. According to this control signal, the virtualization device  20  identifies the processor  10  which is making the access. Depending on the type of the processor  10 , the processor  10  itself may output information equivalent to a control signal. This eliminates the need to dispose the decoder  11 , since the virtualization device  20  is only required to identify the processor  10  and the process in accordance with the information outputted by the processor  10 . 
         [0039]    The hardware shown in  FIG. 2  may be formed on a single semiconductor chip. That is, the virtualization system according to this embodiment may be formed as an SoC (System on a Chip). Alternatively, rather than as an SoC, the virtualization system may be formed as a device having the individual components (processors  10 , virtualization device  20 , and the like) formed therein as different electronic circuits. 
         [0040]      FIG. 3  is a diagram showing a virtualization technique using the virtualization device  20  according to this embodiment. 
         [0041]    As shown in  FIG. 3 , when a processor  10  makes a memory access, the virtualization device  20  receives an access instruction containing a logical address (virtual address) indicating the access destination and a control signal. If the access is intended to write data, the virtualization device  20  also receives data to be written to the memory (boot memory  41  or system memory  42 ). The virtualization device  20  has multiple address translation tables corresponding to the OSs installed on the system. Using a table corresponding to an OS identified by the received control signal, the virtualization device  20  translates an access destination logical address contained in the access instruction into a physical address. The virtualization device  20  (address translation device) then sends the address-translated access instruction to the boot memory controller  31  or system memory controller  32 . 
         [0042]    As for the received data, the virtualization device  20  sends it to the boot memory controller  31  or system memory controller  32  as it is. If the access is intended to read data, the virtualization device  20  returns data read from the memory to the processor  10  as it is. Note that the virtualization device  20  may perform on the passing data a particular process having no effect on the access purpose. For example, in writing data to the memory, the virtualization device  20  may perform a process such as encryption or compression on the received data and then send the resulting data to the memory. On the other hand, when reading data from the memory, it may perform a process such as decryption or decompression on the read data and then send the resulting data to the processor  10 . 
         [0043]      FIG. 4  is a diagram showing an example function configuration of the virtualization device  20 . 
         [0044]    As shown in  FIG. 4 , the virtualization device  20  includes multiple address tables  21 , a table selection unit  22 , an I/O table  23 , and an exclusive control unit  24 . The address tables  21  and the I/O table  23  are composed of, for example, programmable logic and a register and configured in accordance with the system configuration, including the types and number of the installed OSs and the capacities of the boot memory  41  and the system memory  42 . 
         [0045]    The address tables  21  are tables for performing translation using hardware (address translation units, translation units) and translate a logical address specified as the access destination in an access instruction from a processor  10  into an physical address in the memory (e.g., the system memory  42 ). As described above, the multiple address tables  21  corresponding to the OSs installed in the system are prepared. For example, three address tables  21  ( 21   a ,  21   b ,  21   c ) corresponding to three OSs are shown in the diagram. Settings for performing address translation related to access to the boot memory  41  and settings for performing address translation related to access to the system memory  42  are made in each address table  21 . 
         [0046]    In  FIG. 4 , for example, three boot areas (memory areas), a 1 , a 2 , and a 3 , corresponding to the multiple OSs are set in the boot memory  41 . Each area is storing a boot program for booting the corresponding OS. For example, three memory spaces (memory areas), s 1 , s 2 , and s 3 , corresponding to the OSs are set in the system memory  42 . Each memory space is an area used when the corresponding OS makes a memory access. Accordingly, assuming that the boot area a 1  of the boot memory  41  and the memory space s 1  of the system memory  42  correspond to a particular OS, OS  1 , and that the address table  21   a  is prepared for the OS  1 , the address table  21   a  is configured so that address translation of the boot area a 1  and the memory space s 1  is performed, as shown in  FIG. 4 . 
         [0047]    When an OS makes a memory access, the table selection unit  22  selects an address table  21  corresponding to the OS in accordance with a control signal received from a processor  10  or decoder  11  corresponding to the OS. The access destination address in the memory access is translated in accordance with the address table  21  selected by the table selection unit  22 . 
         [0048]    The I/O table  23  manages an address assigned to the external device (input/output device). In this embodiment, MMIO (Memory-Mapped I/O) is used for input/output to the external device. That is, the address assigned to the external device is placed in the same address space as that of the memory. Since there is a need to manage the address assigned to the external device, the I/O table  23  is prepared. The number of addresses assigned to the external device may be one regardless of the OS. For this reason, in this embodiment, the single I/O table  23  is prepared unlike the address tables  21 . 
         [0049]    When one of the OSs is accessing the external device, the exclusive control unit  24  performs exclusive control so that the other OSs do not access the external device. As described above, in this embodiment, each OS uses the common I/O table  23  in order to access the external device. For this reason, exclusive control is performed so that multiple OSs do not access the same external device in an overlapped manner. Exclusive control related to input/output to the external device may be performed by a bus arbiter (not shown) disposed on the second local bus  52 . In this case, the virtualization device  20  does not need to include the exclusive control unit  24 . 
         [0050]    Next, a specific implementation example according to this embodiment will be described. 
         [0051]    First, the specification of this implementation example will be described specifically. The following system is considered in this implementation example. 
         [0052]    Four 32-bit (4-gigabyte (GB) memory space) processors  10 A to  10 D are provided as processors  10 . 
         [0053]    The four-GB system memory  42  and the 756-kilobyte (KB) boot memory  41  are provided as the memory. 
         [0054]    The boot memory controller  31  and the system memory controller  32  are addressed with 34 bits. 
         [0055]    Three OSs, OS  1  to OS  3 , are installed. 
         [0056]    The OS  1  is run by processors  10 A and  10 B and uses the system memory  42  by 2 GB. The address table  21   a  is prepared for the OS  1 . 
         [0057]    The OS  2  is run by a processor  10 C and uses the system memory  42  by 1 GB. The address table  21   b  is prepared for the OS  2 . 
         [0058]    The OS  3  is run by a processor  10 D and uses the system memory  42  by 1 GB. The address table  21   c  is prepared for the OS  3 . 
         [0059]      FIG. 5  shows the memory maps of the OSs, the assignment of the memory spaces of the system memory  42  to the OSs, and the assignment of the boot areas of the boot memory  41  to the OSs in this implementation example. 
         [0060]    One cell represents a  256 -KB area in the shown memory map and memory assignment table. 
         [0061]    In the memory map of the OS  1  of  FIG. 5 , the memory space of the system memory  42  is assigned to the addresses 0x0000 — 0000 to 0x7FFF_FFFF; MMIO is assigned to the addresses 0x8000 — 0000 to 0x8FFF_FFFF; and the boot memory  41  is assigned to the addresses 0xF000 — 0000 to 0xFFFF_FFFF. 
         [0062]    Likewise, in the memory maps of the OS  2  and OS  3 , the memory space of the system memory  42  is assigned to the addresses 0x0000 — 0000 to 0x3FFF_FFFF; MMIO is assigned to the addresses 0x8000 — 0000 to 0x8FFF_FFFF; and the boot memory  41  is assigned to the addresses 0xF000 — 0000 to 0xFFFF_FFFF. 
         [0063]    In the assignment of the memory space of the system memory  42 , the memory space of the OS  1  is assigned to the addresses 0x0000 — 0000 to 0x7FFF_FFFF; the memory space of the OS  2  is assigned to the addresses 0x8000 — 0000 to 0xBFFF_FFFF; and the memory space of the OS  3  is assigned to the addresses 0xC000 — 0000 to 0xFFFF_FFFF. 
         [0064]    In the assignment of the boot area to the boot memory  41 , the boot area of the OS  1  is assigned to the addresses 0x0000 — 0000 to 0x0FFF_FFFF; the boot area of the OS  2  is assigned to the addresses 0x1000 — 0000 to 0x1FFF_FFFF; and the boot area of the OS  3  is assigned to the addresses 0x2000 — 0000 to 0x2FFF_FFFF. 
         [0065]      FIG. 6  is a diagram showing the configuration of the implementation example of the virtualization system according to this embodiment. 
         [0066]    In the implementation example shown in  FIG. 6 , a switch box  22   a  and a multiplexer  22   b  are disposed as the table selection unit  22 . The multiplexer  22   b  receives address signals (signals representing translated addresses) outputted from the address tables  21  and outputs one of the signals. Upon receipt of a control signal from a decoder  11 , the switch box  22   a  controls the multiplexer  22   b  so that the multiplexer  22   b  outputs an address signal outputted from a address table  21  corresponding to a processor  10  specified in the control signal. In this implementation example, the processors  10  use an IP block control bus (not shown) in order to configure the switch box  22   a  and the address tables  21 . 
         [0067]    Further, in this implementation example, exclusive control related to input/output to the external device is performed by the bus arbiter disposed on the second local bus  52 . Accordingly, the virtualization device  20  does not include the exclusive control unit  24 . 
         [0068]    In this implementation example, the processors  10 A and  10 B are configured as symmetric multiple processors (SMPs), run by the same OS, the OS  1 , and commonly use the address table  21   a  for address translation. The processor  10 C is run by the OS  2  and uses the address table  21   b  for address translation. The processor  10 D is run by the OS  3  and uses the address table  21   c  for address translation. In the example shown in  FIG. 6 , the processors  10 A to  10 D are provided with decoders  11 A to  11 D, respectively. Note that if the processors  10 A to  10 D themselves output a control signal, the decoders  11 A to  11 D are not needed. 
         [0069]    The boot memory  41  includes a boot area a 1  (0x1D000 — 0000-0x1DFFF_FFFF) for the OS  1 , a boot area a 2  (0x1E000 — 0000-0x1EFFF_FFFF) for the OS  2 , and a boot area a 3  (0x1F000 — 0000-0x1FFFF_FFFF) for the OS  3 . In  FIG. 6 , the addresses of the boot areas a 1 , a 2 , and a 3  of the boot memory  41  are represented by 34-bit system address space. 
         [0070]    The system memory  42  includes a memory space s 1  (0x0000 — 0000-0x7FFF_FFFF) for the OS  1 , a memory space s 2  (0x8000 — 0000-0xBFFF_FFFF) for the OS  2 , and a memory space s 3  (0xC000 — 0000-0xFFFF_FFFF) for the OS  3 . 
         [0071]      FIG. 6  shows the initial state of the system thus configured (a state where settings for virtualization are not made for any of the switch box  22   a  included in the table selection unit  22  and the address tables  21   a  to  21   c ). In this initial state, the virtualization device  20  of this system is configured so that the processor  10 A accesses the corresponding boot area of the boot memory  41 , reads a boot program, and executes it. 
         [0072]    In  FIG. 6 , the switch box  22   a  is configured to select the address table  21   a  in accordance with a control signal from the decoder  11 A of the processor  10 A. (See a broken line in the diagram) Addresses (“ROM ADD” and “ROM Mask”) of the boot area a 1  of the boot memory  41  are set in the address table  21   a . No other settings are made: no other settings are made for the switch box  22   a ; addresses (“Sys ADD” and “Sys Mask”) of the memory space s 1  of the system memory  42  are not set in the address table  21   a ; and no settings are made for the address table  21   bs  and  21   c.    
         [0073]    When the reset of the processor  10 A is released by power-on or the like in this state, the switch box  22   a  controls the multiplexer  22   b  in accordance with a control signal from the decoder  11 A, thereby selecting the address table  21   a . According to the setting of the address table  21   a , the processor  10 A accesses the boot area a 1  of the boot memory  41  to execute a boot program. Due to the execution of this boot program, settings are made for the switch box  22   a ; settings about the memory space s 1  corresponding to the processor  10 A of the system memory  42  are made for the address table  21   a ; and settings about other processors,  10 B and  10 C, are made. 
         [0074]      FIG. 7  shows a state in which the above-mentioned settings are made in the implementation example of the virtualization system shown in  FIG. 6 . 
         [0075]    Specifically, first, the switch box  22   a  is configured to select the address table  21   a  in accordance with a control signal from the decoder  11 A, select the address table  21   a  in accordance with a control signal from the decoder  11 B, select the address table  21   b  in accordance with a control signal from the decoder  11 C, and select the address table  21   c  in accordance with a control signal from the decoder  11 D. (See Broken Lines in the Diagram.) 
         [0076]    Further, based on the memory map of the OS  1  shown in  FIG. 5 , the addresses 0x0000 — 0000 to 0x7FFF_FFFF of the memory space s 1  of the system memory  42  are set in the address table  21   a . For example, the start address (“Sys ADD”) and mask data for setting the data range (“Sys Mask”) are set as shown in  FIG. 7 . The address can be translated by obtaining AND of an address (logical address) contained in the access instruction outputted by the processor  10 A, and the start address and the mask data. 
         [0077]    Further, addresses in the boot area a 2  of the boot memory  41  and addresses in the memory space s 2  of the system memory  42  are set in the address table  21   b  for the OS  2 . Likewise, addresses in the boot area a 3  of the boot memory  41  and addresses in the memory space s 3  of the system memory  42  are set in the address table  21   c  for the OS  3 . 
         [0078]    Due to the above-mentioned settings, the processor  10 A can use the system memory  42 . For example, by copying the boot program to the system memory  42 , the processor  10 A boots the OS  1 . 
         [0079]    Next, the reset of the processor  10 B is released. Since the processors  10 A and  10 B are SMPs in this implementation example as described above, the processor  10 B uses the same address table,  21   a , as the processor  10 A does. 
         [0080]    Next, the reset of the processor  10 C is released. The addresses in the boot area a 2  of the boot memory  41  and the addresses in the memory space s 2  of the system memory  42  have already been set in the address table  21   b  for the OS  2  run by the processor  10 C. Accordingly, the processor  10 C routinely boots the OS  2 . 
         [0081]    Further, the reset of the processor  10 D is released. The addresses in the boot area a 3  of the boot memory  41  and the addresses in the memory space s 3  of the system memory  42  have already been set in the address table  21   c  for the OS  3  run by the processor  10 D. Accordingly, the processor  10 D routinely boots the OS  3 . 
         [0082]    In the above-mentioned example, the reset of the processor  10 A is first released and the settings are then made for the switch box  22   a  and the address tables  21   a ,  21   b , and  21   c , thereby starting the entire virtualization system. Note that the processor that is first released from the reset can be previously determined using a hardware setting ( FIG. 6 ) and is not limited to a particular processor, the processor  10 . Further, the setting operation at start is not limited to the procedure of the above-mentioned implementation example, as long as each processor  10  can access the corresponding area of the memory (boot memory  41  and system memory  42 ) and the OSs run by the processors  10  can boot while using the system memory  42 . 
         [0083]    As described above, when an installed OS makes an access, the virtualization device  20  according to this embodiment performs address translation (logical address-to-physical address translation) so that a memory area previously assigned to the OS is used. Accordingly, each OS can run in a virtual environment provided by this embodiment without having to be designed or modified so as to be usable in a virtualization system. 
         [0084]    Further, in this embodiment, the virtualization device  20  performs address translation when a memory access is made. This eliminates a need for a mechanism which creates a virtual environment using software such as a host OS or hypervisor. Thus, the loads imposed on the processors can be reduced. 
         [0085]    While this embodiment has been described, the technical scope is not limited to the above-mentioned embodiment. It is apparent from the appended claims that various changes and modifications made to the above-mentioned embodiment can fall within the technical scope of the invention.