WO2017006458A1 - 計算機及びメモリ領域管理方法 - Google Patents

計算機及びメモリ領域管理方法 Download PDF

Info

Publication number
WO2017006458A1
WO2017006458A1 PCT/JP2015/069628 JP2015069628W WO2017006458A1 WO 2017006458 A1 WO2017006458 A1 WO 2017006458A1 JP 2015069628 W JP2015069628 W JP 2015069628W WO 2017006458 A1 WO2017006458 A1 WO 2017006458A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
shared area
application
computer
area
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2015/069628
Other languages
English (en)
French (fr)
Inventor
ゆかり 八田
典充 早川
崇夫 戸塚
俊臣 森木
聡 衣川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to US15/741,704 priority Critical patent/US10289564B2/en
Priority to PCT/JP2015/069628 priority patent/WO2017006458A1/ja
Priority to JP2017527033A priority patent/JP6458146B2/ja
Priority to CN201580081422.9A priority patent/CN107710160B/zh
Publication of WO2017006458A1 publication Critical patent/WO2017006458A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/109—Address translation for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1041—Resource optimization
    • G06F2212/1044—Space efficiency improvement
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/151—Emulated environment, e.g. virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45545—Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox

Definitions

  • the present invention relates to a technique for controlling a memory area shared by a host OS and a guest OS managed by the host OS or another host OS in a computer system that operates a plurality of host OSs.
  • Patent Document 1 states that a multi-operating system computer includes a first OS (operating system) that executes a plurality of tasks with priorities set in order of priority, and a second OS that is different from the first OS.
  • a multi-operating system computer that alternately operates as an operating OS, and is a predetermined task having a predetermined priority set among the plurality of tasks when the first OS is operating as an operating OS.
  • an OS switching unit that switches the operating OS from the first OS to the second OS when a task used as a switching trigger task for identifying a switching trigger for the operating OS is executed. Has been.
  • Patent Document 2 states that “(1) a multi-OS booting apparatus that boots at least two OSes, a first OS and a second OS, has (1) a memory area, and a memory space for the memory area. (2) a secondary storage unit that stores a second boot loader and the second OS, and (3) a context indicating control information for the CPU, the first OS By operating a first boot loader operating under the first OS operating in the first context that is a context for the first OS operating under the first context, The memory area of the primary storage unit defined by the first context as the first memory space managed by the first OS is transferred from the secondary storage unit to the memory area of the primary storage unit.
  • the second boot loader context is generated in the second boot loader and the second boot loader context is defined from the first context to the generated second boot loader context. Let's switch to the context for the second bootloader By executing the second boot loader, the memory of the primary storage unit is stored in the memory area of the primary storage unit defined as the second memory space included in the third memory space by the first boot loader.
  • the second OS loaded in the area is loaded into the second boot loader and the context for the second OS is generated, and the context for the second boot loader is switched to the generated context for the second OS.
  • a loader execution unit that causes the second boot loader to start the second OS under the context for the second OS ”.
  • a host OS 1 is mounted as a first OS (host OS 1)
  • a hypervisor is mounted as a second OS (host OS 2)
  • OSs on a plurality of logical computers on the hypervisor are installed.
  • server control OS as (guest OS1 to guest OSn)
  • An example is a computer system in which a single physical computer and a non-volatile storage medium are connected, and the host OS 1 that controls access to the non-volatile storage medium and a host OS 2 that manages a plurality of guest OSs are mounted on the physical computer.
  • the host OS 1 that controls access to the non-volatile storage medium
  • a host OS 2 that manages a plurality of guest OSs are mounted on the physical computer.
  • Each guest OS has a memory for caching data in order to improve the response performance of I / O processing. Since the memory is volatile, the host OS 1 or the host OS 2 saves the data in a non-volatile storage medium so that the data is not lost when an unexpected power interruption occurs. When the power is restored and the guest OS is restarted, the application on the guest OS communicates with the host OS 1 that can access the nonvolatile storage medium in order to return the saved data to the memory. It is necessary to return the data output from the host OS1 to the memory.
  • a computer that secures a memory area used for communication control between a virtual machine managed by one host OS and the host OS or another host OS, And a memory area management method.
  • a typical example of the invention disclosed in the present application is as follows. That is, a computer that operates a plurality of operating systems, and the computer includes, as computer resources, a processor, a memory connected to the processor, and an I / O device connected to the processor. A plurality of operating systems connected to a storage device having a plurality of storage media, the first operating system for controlling access to the storage device, and a second operating system for generating at least one virtual machine; The first operating system and the second operating system are assigned the divided computer resources, and a third operating system that executes an application on the at least one virtual machine.
  • the second operating system has a shared area management unit that manages a shared area that is a memory area used for communication between the application and the first operating system,
  • the operating system 3 requests the second operating system to secure the shared area in response to a request from the application, and sets a virtual memory location allocated to the application in a guest virtual address space.
  • An agent for mapping the reserved shared area is provided.
  • -A memory area can be shared among multiple operating systems, and data can be sent and received via the memory area.
  • FIG. 3 is a diagram illustrating an example of a hardware configuration of a computer system according to the first embodiment.
  • 1 is a diagram illustrating an example of a logical configuration of a computer system according to a first embodiment. It is a figure which shows an example of the management information of Example 1. It is a figure which shows the mapping relationship and structure of a common area
  • FIG. FIG. 6 is a sequence diagram illustrating a flow of processing using a shared area of the computer system according to the first embodiment.
  • FIG. 6 is a sequence diagram illustrating a flow of processing using a shared area of the computer system according to the first embodiment.
  • 7 is a flowchart illustrating an example of a mapping process executed by an agent according to the first embodiment.
  • FIG. 1 is a diagram illustrating an example of a hardware configuration of the computer system according to the first embodiment.
  • the computer system includes a physical computer 10 and an external storage device 20.
  • the physical computer 10 is connected to the external storage apparatus 20 directly or via a network.
  • SAN etc. comprised by FC (Fibre Channel) can be considered.
  • the physical computer 10 includes a processor 110, a RAM 120, a chip set 130, an FPGA 140, an internal storage device 150, a power supply unit 160, and an I / O device 170.
  • the processor 110 reads a program (instruction) stored in the RAM 120 and executes the read program (instruction).
  • the processor 110 has a plurality of CPU cores 111. Functions such as an OS are realized by the processor 110 executing the program.
  • processing is mainly described with respect to a program, it indicates that the program is being executed by the processor 110.
  • the RAM 120 stores a program executed by the processor 110 and information necessary for executing the program.
  • the RAM 120 includes a work area for each program.
  • the chip set 130 manages input / output of data among the processor 110, the RAM 120, and the I / O device 170.
  • the FPGA 140 is a circuit that performs a predetermined calculation. In this embodiment, the FPGA 140 performs data transfer and the like. Note that the FPGA 140 includes a RAM 141.
  • the internal storage device 150 is a non-volatile storage medium, for example, HDD (Hard Disk Drive) or SSD (Solid State Drive).
  • HDD Hard Disk Drive
  • SSD Solid State Drive
  • data stored in the RAM 141 is stored in the internal storage device 150 when the power is unexpectedly shut off.
  • data stored in the RAM 1120 may be stored in the internal storage device 150.
  • the power supply unit 160 controls the power supply of the physical computer 10.
  • the I / O device 170 is a device for inputting information from outside and outputting information to the outside by connecting to an external device.
  • the I / O device 170 may be, for example, NIC, FC HBA, or the like.
  • the external storage device 20 stores an OS program, program codes of various applications operating on the OS, data handled by the application, and the like.
  • the external storage device 20 includes a plurality of storage media.
  • the external storage apparatus 20 includes four HDDs 190 as storage media.
  • the physical computer 10 may be connected to a storage system including a plurality of storage media and a controller.
  • FIG. 2 is a diagram illustrating an example of a logical configuration of the computer system according to the first embodiment.
  • the computer resources of the physical computer 10 are divided, and the divided computer resources are allocated to the host OS 1 (200) and the host OS 2 (210), respectively.
  • the computer resource includes the RAM 120.
  • the memory area (storage area) of the RAM 120 is divided into two, and the divided memory areas are allocated to the host OS 1 (200) and the host OS 2 (210), respectively.
  • the divided memory area is also referred to as a divided RAM.
  • the computer resources allocated to the host OS 1 (200) are exclusively used by the host OS 1 (200), and the computer resources allocated to the host OS 2 (210) are exclusively used by the host OS 2 (210). .
  • the host OS 1 (200) of this embodiment corresponds to the storage control OS.
  • the storage control OS controls read processing and write processing for the external storage apparatus 20.
  • the host OS 1 (200) executes backup processing and restore processing between the guest OS 230 and the internal storage device 150.
  • the host OS 2 (210) of this embodiment corresponds to a VMM (Virtual Machine Monitor) such as a hypervisor.
  • the VMM creates one or more virtual machines (LPAR 220) using a part of the computer resources allocated to the host OS 2 (210) using the virtual machine technology, and starts the guest OS 230 on the created LPAR 220.
  • LPAR 220 virtual machines
  • an application 232 that performs a predetermined process is further operated.
  • the host OS 2 (210) manages the mapping between the host physical address space of the divided RAM assigned to the host OS 2 (210) and the guest physical address space of the logical RAM assigned to the LPAR 220.
  • the host physical address space of the divided RAM is an address space indicating the physical location of the divided RAM.
  • the guest physical address space of the logical RAM is an address space indicating the physical location of the logical RAM.
  • the host OS 1 (200) also manages the host physical address of the divided RAM allocated to itself.
  • the guest OS 230 manages mapping between the guest physical address space of the logical RAM and the guest virtual address space.
  • the guest virtual address space is an address space indicating the position of the virtual RAM to which the guest OS 230 is assigned to the application 232.
  • the LPAR 220 includes a logical processor, a logical RAM (logical memory), and a logical I / O device.
  • the host OS 2 (210) of this embodiment allocates the shared area 221 to the LPAR 220.
  • the shared area 221 is a memory area used for communication between the application 232 and the host OS 1 (200).
  • the host OS 2 (210) of this embodiment has a shared area management unit 211 and a processing unit 212, and holds management information 213.
  • the shared area management unit 211 allocates a shared area 221 to the LPAR 220 and manages the shared area 221.
  • the shared area management unit 211 divides the shared area 221 into a plurality of blocks, and manages the state of the shared area 221 in units of blocks. In the following description, the block-unit shared area 221 is also simply referred to as a block.
  • the processing unit 212 controls communication between the host OS 1 (200) and the guest OS 230 using the shared area 221.
  • the management information 213 is information for managing the shared area 221 and is managed by the shared area management unit 211. Details of the management information 213 will be described with reference to FIG.
  • the guest OS 230 of this embodiment includes an agent 231.
  • the agent 231 passes a request regarding the shared area 221 issued by the application 232 to the host OS 2 (210), and requests the host OS 2 (210) to secure the shared area 221. Further, the agent 231 maps the shared area 221 secured in the virtual address space, and returns the virtual address to which the shared area 221 is mapped to the application 232. As a result, the application 232 can use the shared area 221.
  • FIG. 3 is a diagram illustrating an example of the management information 213 according to the first embodiment.
  • Management information 213 includes a block ID 301, a guest physical address 302, a host physical address 303, a size 304, and an allocation state 305.
  • Block ID 301 is a block identification number.
  • the guest physical address 302 is a block start address in the guest physical address space.
  • the host physical address 303 is a start address of a block in the host physical address space.
  • the size 304 is a block size. In this embodiment, it is assumed that the size of all the blocks is the same. Note that the size of each block may be different.
  • the allocation state 305 is information indicating whether or not a block is allocated to the application 232. In the allocation state 305 of this embodiment, either “ON” or “OFF” is stored. When the allocation state 305 is “ON”, it indicates that the block is allocated to the application 232. When the allocation state 305 is “OFF”, it indicates that the block is not allocated to the application 232.
  • one shared area 221 is allocated to one LPAR 220. Therefore, the host OS 2 (210) holds the same number of management information 213 as the number of LPARs 220.
  • FIG. 4 is a diagram showing the mapping relationship and structure of the shared area in the first embodiment.
  • the memory area of the RAM 120 of the physical computer 10 is divided into two, and the divided memory areas are assigned to the host OS 1 and the host OS 2 respectively.
  • Each of the host OS 1 (200) and the host OS 2 (210) manages the allocated memory area as an independent host physical address space.
  • the host OS 2 reserves a part of the allocated memory area as a control area for the host OS 2 (210). Further, the host OS 2 (210) secures a part of the allocated memory area as the area of the LPAR 220 and allocates the area to the LPAR 220.
  • the LPAR 220 divides the LPAR 220 area into a guest OS 230 area and an LPAR 220 control area.
  • the guest OS 230 area includes an MMIO area, an F / W area, a RAM area, and an area for controlling the guest OS 230.
  • the host OS 2 (210) allocates the shared area 221 to the control area when the LPAR 220 is activated. That is, a part of the control area is used as the shared area 221.
  • the data structure of the shared area 221 includes a data area and a communication area.
  • the data area is a memory area for storing data transmitted from the host OS 1 (200) in order to perform restoration using data backed up by the host OS 1 (200).
  • the communication area is a memory area used for communication between the application 232 and the host OS 1 (200).
  • the data structure of the shared area 221 shown in FIG. 4 shows a logical structure. Therefore, the data area and the communication area may not be continuous memory areas. Note that by allocating the shared area 221 even during normal startup, for example, the host OS 2 (210) and the application 232 can share the memory.
  • the shared area 221 is different from the area of the guest OS 230, it is a memory area that is not recognized as a logical RAM by the guest OS 230. Further, since the shared area 221 is included in the memory area assigned to the host OS 2, it is not accessed from the host OS 1 (200) except for communication with the application 232.
  • FIG. 5A and FIG. 5B are sequence diagrams illustrating the flow of processing using the shared area 221 of the computer system according to the first embodiment.
  • a restore process using a shared area will be described as an example of a process using a shared area.
  • the host OS 1 (200) backs up the data stored in the RAM 120 for caching to the external storage device 20 when the power supply unit 160 of the physical computer 10 is turned off, such as a failure (step S101). Thereafter, the physical computer 10 restarts.
  • the shared area management unit 211 of the host OS 2 (210) allocates the shared area 221 to the LPAR 220 when the LPAR 220 is activated (step S102).
  • the shared area management unit 211 secures an area for the shared area 221 from the memory area for control among the memory areas allocated to the LPAR 220 when the LPAR 220 is activated.
  • the shared area management unit 211 reserves a memory area where addresses in the host physical address space are continuous as the shared area 221. At this time, the shared area management unit 211 divides the reserved memory area into blocks, and assigns an identification number to each block.
  • the shared area management unit 211 generates entries for the number of blocks in the management information 213, and sets the identification number assigned to the block ID 301. Further, the shared area management unit 211 sets the start address of each block in the host physical address 303 of each entry, and sets the size of each block in the size 304. Furthermore, the shared area management unit 211 sets “OFF” in the allocation state 305 of each entry.
  • the shared area management unit 211 acquires the guest physical address and host physical address of each block based on the address of the reserved memory area, and acquires the guest physical address 302 and host physical address 303 of each entry. Set the guest physical address and host physical address. The above is the description of the processing in step S102.
  • the processing of the application 232 is started.
  • the application 232 determines whether backup processing has been executed. For example, the above-described determination can be made by making an inquiry to the host OS 1 (200) via the host OS 2 (210). Here, it is determined that the backup process has been executed.
  • the application 232 issues a request for securing the shared area 221 to the agent 231 (step S103).
  • the reservation request includes the size of the memory area to be reserved.
  • the agent 231 issues a request for securing the shared area 221 received from the application 232 to the shared area management unit 211 (step S104).
  • the shared area management unit 211 When the shared area management unit 211 receives a request for securing the shared area 221 from the agent 231, the shared area 221 refers to the management information 213 and secures the shared area 221 (block) to be allocated to the guest virtual address space of the application 232 (step S 105). ). That is, a block to be provided to the application 232 is selected. Further, the shared area management unit 211 notifies the agent 231 of the guest physical address to be mapped (step S106).
  • the shared area management unit 211 refers to the allocation state 305 of each entry in the management information 213, and searches for a location where entries whose management information 213 is “OFF” continue for the requested size.
  • the shared area management unit 211 selects the searched entry group, and sets “ON” in the allocation state 305 of the selected entry group.
  • the shared area management unit 211 notifies the agent 231 of values stored in the first block ID 301 and the guest physical address 302 of the selected entry group. At this time, since the address that the shared area management unit 211 passes to the agent is the address to be mapped, the offset to the area used by the application 232 is also notified.
  • the agent 231 When the agent 231 receives the guest physical address from the shared area management unit 211, the agent 231 maps the guest physical address to the guest virtual address space (step S107). In this embodiment, the guest physical address is mapped to the guest virtual address using the function of the OS. Specific processing will be described with reference to FIG.
  • the agent 231 notifies the mapped guest virtual address to the application 232 (step S108).
  • the agent 231 determines the shared area in which the guest virtual address, guest physical address, file descriptor, block identification number, size, etc. of the first block used by the application 232 are secured. Information necessary for release is notified to the application 232.
  • the application 232 When receiving the guest physical address from the agent 231, the application 232 issues a processing start request to the host OS 2 (210) using the shared area 221 in order to start communication with the host OS 1 (200). (Step S109).
  • the start request includes the size included in the request for securing the shared area 221 issued in step S103 and the block identification number received from the agent 231.
  • the agent 231 issues a processing start request received from the application 232 to the processing unit 212 (step S110).
  • the processing unit 212 When receiving the processing start request from the agent 231, the processing unit 212 requests the host physical address of the block secured in the shared area management unit 211 (step S111).
  • the request for the host physical address includes the block identification number issued in step S108 and input in the start request in step S109.
  • the shared area management unit 211 When receiving the request for the host physical address, the shared area management unit 211 notifies the processing unit 212 of the host physical address of the secured block based on the management information 213 (step S112).
  • the shared area management unit 211 refers to the management information 213 and searches for an entry in which the block ID 301 matches the block identification number included in the request for the host physical address.
  • the shared area management unit 211 notifies the processing unit 212 of the address stored in the host physical address 303 of the retrieved entry.
  • the processing unit 212 When receiving the host physical address from the shared area management unit 211, the processing unit 212 notifies the host physical address to the host OS 1 (200) (step S113). At this time, the processing unit 212 also notifies the size included in the input of the start request in step S109 together with the host physical address. Accordingly, the host OS 1 (200) can access the shared area 221 assigned to the application 232.
  • the host OS 1 (200) executes processing using the shared area 221 (step S114).
  • a restore process using the shared area 221 is executed. Since the restore process is well known, detailed description thereof is omitted.
  • the application 232 issues a completion notification to the agent 231 after the restoration process is completed (step S115).
  • the agent 231 issues a completion notification received from the application 232 to the processing unit 212 (step S116).
  • the processing unit 212 When receiving the completion notification from the agent 231, the processing unit 212 issues a completion notification to the host OS 1 (200) (step S117).
  • the host OS 1 (200) When the host OS 1 (200) receives a completion notification from the processing unit 212, the host OS 1 (200) executes a completion process so that the shared area 221 is not accessed thereafter (step S118). Since the completion process is a known process, detailed description thereof is omitted.
  • Application 232 issues a release request to agent 231 (step S119).
  • the release request includes various information received from the agent 231 in step S108.
  • the agent 231 issues the release request received from the application 232 to the shared area management unit 211 (step S120).
  • the shared area management unit 211 When the shared area management unit 211 receives a release request from the agent 231, the shared area management unit 211 releases all the blocks allocated to the application 232 (step S121). At this time, the shared area management unit 211 refers to the management information 213 and updates all the allocation statuses 305 of the entries corresponding to the released blocks to “OFF”.
  • the shared area management unit 211 notifies the agent 231 of an offset for calculating an address for unmapping (step S122).
  • the agent 231 uses the offset to unmap the block from the guest virtual address space (step S123).
  • FIG. 6 is a flowchart illustrating an example of the mapping process executed by the agent 231 according to the first embodiment.
  • the agent 231 opens the special file (step S201).
  • the agent 231 determines whether or not the special file has been successfully opened (step S202).
  • the agent 231 determines that an error has occurred and ends the process.
  • the agent 231 executes mmap in order to map the guest physical address of the block to the guest virtual address (step S203).
  • the agent 231 determines whether mmap is successful (step S204).
  • the agent 231 determines that there is an error and ends the process.
  • the agent 231 returns a guest virtual address to the application 232 as the mmap execution result (step S205).
  • the agent 231 executes mmunmap.
  • the application on the LPAR 220 managed by the host OS 2 and the host A shared area for communication with the OS 1 (200) can be secured.
  • processing such as communication can be performed between the host OS 1 (200) that uses independent computer resources and the application 232 on the host OS 2.
  • the method of using the shared area is not limited to communication between the host OS 1 (200) and the application 232 on the host OS 2.
  • the shared area can be used for communication between the host OS 2 and the application 232 or communication between the host OS 2 and the agent 231.
  • this invention is not limited to the above-mentioned Example, Various modifications are included. Further, for example, the above-described embodiments are described in detail for easy understanding of the present invention, and are not necessarily limited to those provided with all the described configurations. Further, a part of the configuration of each embodiment can be added to, deleted from, or replaced with another configuration.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • the present invention can also be realized by software program codes that implement the functions of the embodiments.
  • a storage medium in which the program code is recorded is provided to the computer, and a processor included in the computer reads the program code stored in the storage medium.
  • the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code itself and the storage medium storing it constitute the present invention.
  • Examples of storage media for supplying such program codes include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, A non-volatile memory card, ROM, or the like is used.
  • program code for realizing the functions described in this embodiment can be implemented by a wide range of programs or script languages such as assembler, C / C ++, Perl, Shell, PHP, Java, and the like.
  • the program code is stored in a storage means such as a hard disk or memory of a computer or a storage medium such as a CD-RW or CD-R.
  • a processor included in the computer may read and execute the program code stored in the storage unit or the storage medium.
  • control lines and information lines indicate those that are considered necessary for the explanation, and do not necessarily indicate all the control lines and information lines on the product. All the components may be connected to each other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

複数のＯＳが稼働する計算機であって、計算機は複数の記憶媒体を有するストレージ装置と接続し、複数のＯＳは、ストレージ装置に対するアクセスを制御する第１のＯＳ、及び仮想計算機を生成する第２のＯＳを含み、第１のＯＳ及び第２のＯＳには、論理的に分割された計算機リソースが割り当てられ、仮想計算機上では、アプリケーションを実行する第３のＯＳが稼動し、第２のＯＳは、アプリケーションと第１のＯＳとの間で通信するために用いられるメモリ領域である共有領域を管理する共有領域管理部を有し、第３のＯＳは、アプリケーションからの要求に応じて第２のＯＳに対して共有領域の確保を要求し、ゲスト仮想アドレス空間に確保された共有領域をマッピングするエージェントを有する。

Description

計算機及びメモリ領域管理方法
　本発明は、複数のホストＯＳが稼働する計算機システムにおいて、ホストＯＳと、当該ホストＯＳ又は他のホストＯＳが管理するゲストＯＳとが共有するメモリ領域の制御技術に関する。
　近年、物理計算機上のハードウェアリソースを有効に活用するために、一台の物理計算機上で二つ以上のＯＳ（オペレーティングシステム）を起動する技術が注目されている（例えば、特許文献１及び特許文献２参照）。
　特許文献１には、「マルチオペレーティングシステム計算機は、優先度が設定された複数のタスクを優先度順に実行する第１のＯＳ（オペレーティングシステム）と、前記第１のＯＳと異なる第２のＯＳとを動作ＯＳとして交互に動作させるマルチオペレーティングシステム計算機であって、前記第１のＯＳが動作ＯＳとして動作しているときに前記複数のタスクのうち所定の優先度が設定された所定のタスクであって動作ＯＳの切替え契機を特定するための切替え契機タスクとして用いられるタスクが実行された場合に、動作ＯＳを前記第１のＯＳから前記第２のＯＳに切り替えるＯＳ切替え部」を備えることが記載されている。
　また、特許文献２には、「第１のＯＳと第２のＯＳとの少なくとも２つのＯＳを起動するマルチＯＳ起動装置において、（１）メモリ領域を有し、前記メモリ領域に対してメモリ空間が定義される１次記憶部と、（２）セカンドブートローダと、前記第２のＯＳとを記憶する２次記憶部と、（３）ＣＰＵに対する制御情報を示すコンテキストであって前記第１のＯＳ用のコンテキストである第１のコンテキストで動作する前記第１のＯＳのもとで動作するファーストブートローダを前記第１のコンテキストで動作中の前記第１のＯＳのもとで動作させることにより、前記第１のＯＳが管理する第１のメモリ空間として前記第１のコンテキストにより前記１次記憶装置に対して定義された前記１次記憶部のメモリ領域に前記２次記憶部から前記セカンドブートローダと前記第２のＯＳとを前記ファーストブートローダにロードさせるＯＳ実行部と、（４）前記第１のメモリ空間として定義されたメモリ領域にロードされた前記セカンドブートローダを前記第１のコンテキストで動作中の前記第１のＯＳのもとで実行することにより前記第２のＯＳが管理する第２のメモリ空間として定義されるメモリ領域と前記セカンドブートローダ及び前記第２のＯＳがロードされたメモリ領域とを含む第３のメモリ空間を前記１次記憶部に対して定義する前記セカンドブートローダ用のコンテキストを前記セカンドブートローダに生成させると共に生成された前記セカンドブートローダ用のコンテキストへ前記第１のコンテキストから切り替えさせ、前記セカンドブートローダ用のコンテキストのもとで前記セカンドブートローダを実行することにより前記第３のメモリ空間に含まれる前記第２のメモリ空間として定義された前記１次記憶部のメモリ領域に前記ファーストブートローダによって前記１次記憶部のメモリ領域にロードされた前記第２のＯＳを前記セカンドブートローダにロードさせると共に前記第２のＯＳ用のコンテキストを生成させ、生成された前記第２のＯＳ用のコンテキストへ前記セカンドブートローダ用のコンテキストから切り替えさせ、前記第２のＯＳ用のコンテキストのもとで前記セカンドブートローダに前記第２のＯＳの起動を実行させるローダ実行部と」を備えることが記載されている。
　このマルチＯＳ技術を利用し、例えば、第１のＯＳ（ホストＯＳ１）としてホストＯＳ１を搭載し、第２のＯＳ（ホストＯＳ２）としてハイパバイザを搭載し、さらにハイパバイザ上の複数の論理計算機上のＯＳ（ゲストＯＳ１～ゲストＯＳｎ）としてサーバ制御ＯＳを搭載することによって、省スペース化・低価格化が期待できる。
特開平１１－１４９３８５号公報 国際公開第２００９／１１３３９４号
　一つの物理計算機と不揮発性の記憶媒体とが接続され、物理計算機に不揮発性の記憶媒体へのアクセスを制御するホストＯＳ１及び複数のゲストＯＳを管理するホストＯＳ２を搭載する計算機システムを一例にして考える。
　各ゲストＯＳはＩ／Ｏ処理の応答性能を高めるために、データをキャッシングするためのメモリを設けている。メモリは揮発性であるため、不意の電源遮断が発生した場合にデータが失われないように、ホストＯＳ１又はホストＯＳ２は、不揮発性の記憶媒体にデータを退避する。電源が復旧し、ゲストＯＳが再起動する場合、退避されたデータをメモリに戻すためには、ゲストＯＳ上のアプリケーションは、不揮発性の記憶媒体にアクセス可能なホストＯＳ１との間で通信を行いホストＯＳ１が出力したデータをメモリ上に戻す必要がある。
　前述したような障害復旧を実現するためには、ホストＯＳ１とゲストＯＳ上のアプリケーションとが通信するためのメモリ領域（共有領域）を確保する必要がある。
　独立した計算機リソースを有する複数のホストＯＳが稼働する計算機において、一つのホストＯＳが管理する仮想計算機と、当該ホストＯＳ又は他のホストＯＳとの間の通信制御に用いるメモリ領域を確保する計算機、及びメモリ領域の管理方法を提供する。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数のオペレーティングシステムが稼働する計算機であって、前記計算機は、計算機リソースとして、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるＩ／Ｏデバイスを備え、前記計算機は、複数の記憶媒体を有するストレージ装置と接続し、前記複数のオペレーティングシステムは、前記ストレージ装置に対するアクセスを制御する第１のオペレーティングシステム、及び少なくとも一つの仮想計算機を生成する第２のオペレーティングシステムを含み、前記第１のオペレーティングシステム及び前記第２のオペレーティングシステムには、分割された前記計算機リソースが割り当てられ、前記少なくとも一つの仮想計算機上では、アプリケーションを実行する第３のオペレーティングシステムが稼動し、前記第２のオペレーティングシステムは、前記アプリケーションと前記第１のオペレーティングシステムとの間で通信するために用いられるメモリ領域である共有領域を管理する共有領域管理部を有し、前記第３のオペレーティングシステムは、前記アプリケーションからの要求に応じて前記第２のオペレーティングシステムに対して前記共有領域の確保を要求し、前記アプリケーションに割り当てられる仮想的なメモリの位置を示すゲスト仮想アドレス空間に前記確保された共有領域をマッピングするエージェントを有することを特徴とする。
　複数のオペレーティングシステム間でメモリ領域を共有し、当該メモリ領域を介してデータの送受信が可能となる。前述した以外の課題、構成及び効果は、以下の実施形態の説明によって明らかにされる。
実施例１の計算機システムのハードウェア構成の一例を示す図である。 実施例１の計算機システムの論理構成の一例を示す図である。 実施例１の管理情報の一例を示す図である。 実施例１の共有領域のマッピング関係及び構造を示す図である。 実施例１の計算機システムの共有領域を用いた処理の流れを示すシーケンス図である。 実施例１の計算機システムの共有領域を用いた処理の流れを示すシーケンス図である。 実施例１のエージェントが実行するマッピング処理の一例を説明するフローチャートである。
　以下、図面を用いて実施例を説明する。
　図１は、実施例１の計算機システムのハードウェア構成の一例を示す図である。
　計算機システムは、物理計算機１０及び外部ストレージ装置２０から構成される。物理計算機１０は、外部ストレージ装置２０と直接、又は、ネットワークを介して接続される。ネットワークとしては、ＦＣ（Ｆｉｂｒｅ　Ｃｈａｎｎｅｌ）で構成されたＳＡＮ等が考えられる。
　物理計算機１０は、プロセッサ１１０、ＲＡＭ１２０、チップセット１３０、ＦＰＧＡ１４０、内部ストレージデバイス１５０、電源部１６０、及びＩ／Ｏデバイス１７０を備える。
　プロセッサ１１０は、ＲＡＭ１２０に格納されるプログラム（命令）を読み出し、読み出されたプログラム（命令）を実行する。プロセッサ１１０は、複数のＣＰＵコア１１１を有する。プロセッサ１１０がプログラムを実行することによって、ＯＳ等の機能が実現される。以下、プログラムを主体に処理を説明する場合、当該プログラムがプロセッサ１１０によって実行されていることを示す。
　ＲＡＭ１２０は、プロセッサ１１０によって実行されるプログラム及び当該プログラムの実行に必要な情報を格納する。また、ＲＡＭ１２０は、各プログラムのワークエリアを含む。
　チップセット１３０は、プロセッサ１１０、ＲＡＭ１２０、及びＩ／Ｏデバイス１７０間のデータの入出力を管理する。ＦＰＧＡ１４０は、所定の演算を行う回路である。本実施例では、ＦＰＧＡ１４０は、データ転送等を行う。なお、ＦＰＧＡ１４０は、ＲＡＭ１４１を含む。
　内部ストレージデバイス１５０は、不揮発性の記憶媒体であり、例えば、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等が考えられる。本実施例では、不意に電源が遮断した時に、ＲＡＭ１４１に格納されるデータが内部ストレージデバイス１５０に格納される。なお、ＲＡＭ１１２０に格納されるデータが内部ストレージデバイス１５０に格納されてもよい。
　電源部１６０は、物理計算機１０の電源を制御する。Ｉ／Ｏデバイス１７０は、外部装置と接続することによって、外部から情報を入力し、外部に情報を出力するためのデバイスである。Ｉ／Ｏデバイス１７０は、例えば、ＮＩＣ、ＦＣ　ＨＢＡ等が考えられる。
　外部ストレージ装置２０は、ＯＳのプログラム、ＯＳ上で動作する各種アプリケーションのプログラムコード、及びアプリケーションが扱うデータ等を格納する。外部ストレージ装置２０は、複数の記憶媒体を備える。本実施例では、外部ストレージ装置２０は、記憶媒体として四つのＨＤＤ１９０を備える。なお、物理計算機１０は、複数の記憶媒体、及びコントローラを備えるストレージシステムと接続されてもよい。
　図２は、実施例１の計算機システムの論理構成の一例を示す図である。
　本実施例の計算機システムでは、物理計算機１０の計算機リソースが分割され、ホストＯＳ１（２００）及びホストＯＳ２（２１０）のそれぞれに分割された計算機リソースが割り当てられる。計算機リソースには、ＲＡＭ１２０が含まれる。本実施例では、ＲＡＭ１２０のメモリ領域（記憶領域）が二つに分割され、ホストＯＳ１（２００）及びホストＯＳ２（２１０）のそれぞれに分割されたメモリ領域が割り当てられる。以下の説明では、分割されたメモリ領域を分割ＲＡＭとも記載する。
　ホストＯＳ１（２００）に割り当てられた計算機リソースは、ホストＯＳ１（２００）によって占有的に使用され、ホストＯＳ２（２１０）に割り当てられた計算機リソースは、ホストＯＳ２（２１０）によって占有的に使用される。
　本実施例のホストＯＳ１（２００）は、ストレージ制御ＯＳに対応する。ストレージ制御ＯＳは、外部ストレージ装置２０に対する読出処理及び書込処理を制御する。ホストＯＳ１（２００）は、ゲストＯＳ２３０と内部ストレージデバイス１５０との間のバックアップ処理及びリストア処理を実行する。
　本実施例のホストＯＳ２（２１０）は、ハイパバイザ等のＶＭＭ（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｍｏｎｉｔｏｒ）に対応する。ＶＭＭは、仮想マシン技術を用いて、ホストＯＳ２（２１０）に割り当てられた計算機リソースの一部を用いて一つ以上の仮想計算機（ＬＰＡＲ２２０）を生成し、生成されたＬＰＡＲ２２０上でゲストＯＳ２３０を起動させる。ゲストＯＳ２３０では、さらに、所定の処理を行うアプリケーション２３２が稼働する。
　ホストＯＳ２（２１０）は、ホストＯＳ２（２１０）に割り当てられた分割ＲＡＭのホスト物理アドレス空間と、ＬＰＡＲ２２０に割り当てられた論理ＲＡＭのゲスト物理アドレス空間との間のマッピングを管理する。
　分割ＲＡＭのホスト物理アドレス空間は、分割ＲＡＭの物理的な位置を示すアドレス空間である。論理ＲＡＭのゲスト物理アドレス空間は、論理ＲＡＭの物理的な位置を示すアドレス空間である。なお、ホストＯＳ１（２００）も、自身に割り当てられた分割ＲＡＭのホスト物理アドレスを管理する。
　ゲストＯＳ２３０は、論理ＲＡＭのゲスト物理アドレス空間とゲスト仮想アドレス空間との間のマッピングを管理する。ここで、ゲスト仮想アドレス空間は、ゲストＯＳ２３０がアプリケーション２３２に割り当てられる仮想的なＲＡＭの位置を示すアドレス空間である。
　ＬＰＡＲ２２０は、論理プロセッサ、論理ＲＡＭ（論理メモリ）、及び論理Ｉ／Ｏデバイスを有する。本実施例のホストＯＳ２（２１０）は、ＬＰＡＲ２２０に対して共有領域２２１を割り当てる。共有領域２２１は、アプリケーション２３２とホストＯＳ１（２００）との間の通信等に用いられるメモリ領域である。
　本実施例のホストＯＳ２（２１０）は、共有領域管理部２１１及び処理部２１２を有し、また、管理情報２１３を保持する。
　共有領域管理部２１１は、ＬＰＡＲ２２０に対して共有領域２２１を割り当て、当該共有領域２２１を管理する。共有領域管理部２１１は、共有領域２２１を複数のブロックに分割し、ブロック単位に共有領域２２１の状態を管理する。以下の説明ではブロック単位の共有領域２２１を単にブロックとも記載する。処理部２１２は、共有領域２２１を用いたホストＯＳ１（２００）とゲストＯＳ２３０との間の通信を制御する。管理情報２１３は、共有領域２２１を管理するための情報であり、共有領域管理部２１１によって管理される。管理情報２１３の詳細については図３を用いて説明する。
　本実施例のゲストＯＳ２３０は、エージェント２３１を含む。エージェント２３１は、アプリケーション２３２が発行した共有領域２２１に関する要求をホストＯＳ２（２１０）に渡し、また、ホストＯＳ２（２１０）に対して共有領域２２１の確保を依頼する。また、エージェント２３１は、仮想アドレス空間に確保された共有領域２２１をマッピングし、共有領域２２１がマッピングされた仮想アドレスをアプリケーション２３２に返す。これによって、アプリケーション２３２は、共有領域２２１を使用することができる。
　図３は、実施例１の管理情報２１３の一例を示す図である。
　管理情報２１３は、ブロックＩＤ３０１、ゲスト物理アドレス３０２、ホスト物理アドレス３０３、サイズ３０４、及び割当状態３０５を含む。
　ブロックＩＤ３０１は、ブロックの識別番号である。ゲスト物理アドレス３０２は、ゲスト物理アドレス空間上におけるブロックの開始アドレスである。ホスト物理アドレス３０３は、ホスト物理アドレス空間上におけるブロックの開始アドレスである。サイズ３０４は、ブロックのサイズである。本実施例では、全てのブロックのサイズが同一であるものとする。なお、各ブロックのサイズは異なっていてもよい。
　割当状態３０５は、ブロックがアプリケーション２３２に対して割り当てられているか否かを示す情報である。本実施例の割当状態３０５には「ＯＮ」又は「ＯＦＦ」のいずれかが格納される。割当状態３０５が「ＯＮ」の場合、ブロックがアプリケーション２３２に割り当てられていることを示す。割当状態３０５が「ＯＦＦ」の場合、ブロックがアプリケーション２３２に割り当てられていないことを示す。
　本実施例では、一つのＬＰＡＲ２２０に対して一つの共有領域２２１が割り当てられる。そのため、ホストＯＳ２（２１０）は、ＬＰＡＲ２２０の数と同数の管理情報２１３を保持する。
　図４は、実施例１の共有領域のマッピング関係及び構造を示す図である。
　物理計算機１０のＲＡＭ１２０のメモリ領域は、二つに分割され、ホストＯＳ１及びホストＯＳ２のそれぞれに分割されたメモリ領域が割り当てられる。ホストＯＳ１（２００）及びホストＯＳ２（２１０）のそれぞれは、割り当てられたメモリ領域を独立したホスト物理アドレス空間として管理する。
　ホストＯＳ２（２１０）は、割り当てられたメモリ領域の一部をホストＯＳ２（２１０）の制御用の領域として確保する。また、ホストＯＳ２（２１０）は、割り当てられたメモリ領域の一部をＬＰＡＲ２２０の領域として確保し、ＬＰＡＲ２２０に当該領域を割り当てる。
　ＬＰＡＲ２２０は、ＬＰＡＲ２２０の領域を、ゲストＯＳ２３０の領域と、ＬＰＡＲ２２０の制御用の領域とに分割する。なお、ゲストＯＳ２３０の領域には、ＭＭＩＯ用の領域、Ｆ／Ｗ用の領域、ＲＡＭ用の領域、及びゲストＯＳ２３０の制御用の領域が含まれる。
　ホストＯＳ２（２１０）は、ＬＰＡＲ２２０を起動時に、制御用の領域に、共有領域２２１を割り当てる。すなわち、制御用の領域の一部が共有領域２２１として使用される。共有領域２２１のデータ構造は、データ領域及び通信用領域から構成される。データ領域は、ホストＯＳ１（２００）によってバックアップされたデータを用いたリストアを行うために、ホストＯＳ１（２００）から送信されたデータを格納するメモリ領域である。通信用領域は、アプリケーション２３２とホストＯＳ１（２００）との間で通信に用いるメモリ領域である。
　なお、図４に示す共有領域２２１のデータ構造は論理的な構造を示すものである。したがって、データ領域及び通信用領域は連続的なメモリ領域でなくてもよい。なお、通常起動時にも共有領域２２１を割り当てることによって、例えば、ホストＯＳ２（２１０）及びアプリケーション２３２がメモリを共有すること等ができる。
　図４に示すように、共有領域２２１は、ゲストＯＳ２３０の領域とは異なるため、ゲストＯＳ２３０からは論理ＲＡＭとして認識されないメモリ領域である。また、共有領域２２１は、ホストＯＳ２に割り当てられたメモリ領域に含まれるため、アプリケーション２３２との間の通信以外にはホストＯＳ１（２００）からアクセスされることはない。
　図５Ａ及び図５Ｂは、実施例１の計算機システムの共有領域２２１を用いた処理の流れを示すシーケンス図である。本実施例では、共有領域を用いた処理の一例として、共有領域を用いたリストア処理について説明する。
　ホストＯＳ１（２００）は、物理計算機１０の電源部１６０の障害等の電源遮断時にキャッシング用にＲＡＭ１２０に格納されるデータを外部ストレージ装置２０にバックアップする（ステップＳ１０１）。その後、物理計算機１０は再起動を行う。
　ホストＯＳ２（２１０）の共有領域管理部２１１は、ＬＰＡＲ２２０の起動時に、ＬＰＡＲ２２０に共有領域２２１を割り当てる（ステップＳ１０２）。
　例えば、共有領域管理部２１１は、ＬＰＡＲ２２０の起動時に、ＬＰＡＲ２２０に割り当てられたメモリ領域のうち、制御用のメモリ領域から共有領域２２１用の領域を確保する。
　また、共有領域管理部２１１は、ホスト物理アドレス空間のアドレスが連続するメモリ領域を共有領域２２１として確保する。このとき、共有領域管理部２１１は、確保されたメモリ領域をブロック単位に分割し、各ブロックに識別番号を付与する。
　共有領域管理部２１１は、管理情報２１３にブロックの数だけエントリを生成し、ブロックＩＤ３０１に付与された識別番号を設定する。また、共有領域管理部２１１は、各エントリのホスト物理アドレス３０３に各ブロックの開始アドレスを設定し、また、サイズ３０４に各ブロックのサイズを設定する。さらに、共有領域管理部２１１は、各エントリの割当状態３０５に「ＯＦＦ」を設定する。
　共有領域管理部２１１は、ＬＰＡＲ２２０の起動時、確保されたメモリ領域のアドレスに基づいて各ブロックのゲスト物理アドレス及びホスト物理アドレスを取得し、各エントリのゲスト物理アドレス３０２及びホスト物理アドレス３０３に取得されたゲスト物理アドレス及びホスト物理アドレスを設定する。以上がステップＳ１０２の処理の説明である。
　ＬＰＡＲ２２０が起動し、さらに、ＬＰＡＲ２２０上でゲストＯＳ２３０が起動した後、アプリケーション２３２の処理が開始される。このとき、アプリケーション２３２は、バックアップ処理が実行されたか否かを判定する。例えば、ホストＯＳ２（２１０）を介して、ホストＯＳ１（２００）に対して問い合わせることによって、前述した判定をすることができる。ここでは、バックアップ処理が実行されたと判定するものとする。
　この場合、アプリケーション２３２は、エージェント２３１に対して共有領域２２１の確保要求を発行する（ステップＳ１０３）。なお、当該確保要求には、確保するメモリ領域のサイズが含まれる。
　エージェント２３１は、共有領域管理部２１１にアプリケーション２３２から受け取った共有領域２２１の確保要求を出す（ステップＳ１０４）。
　共有領域管理部２１１は、エージェント２３１から共有領域２２１の確保要求を受信した場合、管理情報２１３を参照して、アプリケーション２３２のゲスト仮想アドレス空間に割り当てる共有領域２２１（ブロック）を確保する（ステップＳ１０５）。すなわち、アプリケーション２３２に提供するブロックが選択される。さらに、共有領域管理部２１１は、マッピングするゲスト物理アドレスをエージェント２３１に通知する（ステップＳ１０６）。
　具体的には、共有領域管理部２１１は、管理情報２１３の各エントリの割当状態３０５を参照し、管理情報２１３が「ＯＦＦ」であるエントリが要求サイズ分連続している箇所を検索する。共有領域管理部２１１は、検索されたエントリ群を選択し、選択されたエントリ群の割当状態３０５に「ＯＮ」を設定する。共有領域管理部２１１は、選択されたエントリ群の先頭のブロックＩＤ３０１及びゲスト物理アドレス３０２に格納される値をエージェント２３１に通知する。このとき、共有領域管理部２１１がエージェントに渡すアドレスは、マッピングするアドレスであるため、アプリケーション２３２に使用させる領域までのオフセットも合わせて通知する。
　エージェント２３１は、共有領域管理部２１１からゲスト物理アドレスを受け取った場合、当該ゲスト物理アドレスをゲスト仮想アドレス空間にマッピングする（ステップＳ１０７）。本実施例では、ＯＳの機能を用いてゲスト物理アドレスがゲスト仮想アドレスにマッピングされる。具体的な処理については図６を用いて説明する。
　エージェント２３１は、マッピングしたゲスト仮想アドレスをアプリケーション２３２に通知する（ステップＳ１０８）。
　具体的には、エージェント２３１は、マッピング結果及びオフセットに基づいて、アプリケーション２３２が使用する先頭ブロックのゲスト仮想アドレス、ゲスト物理アドレス、ファイルディスクリプタ、ブロックの識別番号、サイズ等の確保された共有領域の解放に必要な情報をアプリケーション２３２に通知する。
　アプリケーション２３２は、エージェント２３１からゲスト物理アドレスを受け取った場合、ホストＯＳ１（２００）との通信を開始するために、ホストＯＳ２（２１０）に対して共有領域２２１を用いて処理の開始要求を発行する（ステップＳ１０９）。なお、当該開始要求には、ステップＳ１０３において発行された共有領域２２１の確保要求に含まれるサイズ、及び、エージェント２３１から受け取ったブロックの識別番号が含まれる。
　エージェント２３１は、処理部２１２にアプリケーション２３２から受け取った処理の開始要求を発行する（ステップＳ１１０）。
　処理部２１２は、エージェント２３１から処理の開始要求を受け取った場合、共有領域管理部２１１に確保されたブロックのホスト物理アドレスを要求する（ステップＳ１１１）。当該ホスト物理アドレスの要求には、ステップＳ１０８において発行され、ステップＳ１０９の開始要求で入力されたブロックの識別番号が含まれる。
　共有領域管理部２１１は、ホスト物理アドレスの要求を受け取った場合、管理情報２１３に基づいて、確保されたブロックのホスト物理アドレスを処理部２１２に通知する（ステップＳ１１２）。
　具体的には、共有領域管理部２１１は、管理情報２１３を参照し、ブロックＩＤ３０１がホスト物理アドレスの要求に含まれるブロックの識別番号と一致するエントリを検索する。共有領域管理部２１１は、検索されたエントリのホスト物理アドレス３０３に格納されるアドレスを処理部２１２に通知する。
　処理部２１２は、共有領域管理部２１１からホスト物理アドレスを受け取った場合、ホストＯＳ１（２００）にホスト物理アドレスを通知する（ステップＳ１１３）。このとき、処理部２１２は、ステップＳ１０９の開始要求の入力に含まれるサイズもホスト物理アドレスと合わせて通知する。これによって、ホストＯＳ１（２００）は、アプリケーション２３２に割り当てられた共有領域２２１にアクセスが可能となる。
　ホストＯＳ１（２００）は、ホスト物理アドレスの通知を受け取った場合、共有領域２２１を用いた処理を実行する（ステップＳ１１４）。本実施例では、共有領域２２１を用いたリストア処理が実行される。リストア処理は公知のものであるため詳細な説明は省略する。
　アプリケーション２３２は、リストア処理が完了した後、エージェント２３１に完了通知を発行する（ステップＳ１１５）。エージェント２３１は、処理部２１２にアプリケーション２３２から受け取った完了通知を発行する（ステップＳ１１６）。
　処理部２１２は、エージェント２３１から完了通知を受け取った場合、ホストＯＳ１（２００）に完了通知を発行する（ステップＳ１１７）。
　ホストＯＳ１（２００）は、処理部２１２から完了通知を受け取った場合、これ以降、共有領域２２１へアクセスすることがないように、完了処理を実行する（ステップＳ１１８）。完了処理は公知のものであるため詳細な説明は省略する。
　アプリケーション２３２は、エージェント２３１に解放要求を発行する（ステップＳ１１９）。当該解放要求には、ステップＳ１０８において、エージェント２３１から受け取った各種情報が含まれる。エージェント２３１は、共有領域管理部２１１にアプリケーション２３２から受け取った解放要求を発行する（ステップＳ１２０）。
　共有領域管理部２１１は、エージェント２３１から解放要求を受け取った場合、アプリケーション２３２に対して割り当てられたブロックを全て解放する（ステップＳ１２１）。このとき、共有領域管理部２１１は、管理情報２１３を参照し、解放されたブロックに対応するエントリの割当状態３０５を全て「ＯＦＦ」に更新する。
　共有領域管理部２１１は、アンマップ用のアドレスを算出するためのオフセットをエージェント２３１に通知する（ステップＳ１２２）。
　エージェント２３１は、共有領域管理部２１１からオフセットを受け付けた場合、当該オフセットを用いて、ゲスト仮想アドレス空間からブロックをアンマップする（ステップＳ１２３）。
　図６は、実施例１のエージェント２３１が実行するマッピング処理の一例を説明するフローチャートである。
　エージェント２３１は、スペシャルファイルをｏｐｅｎする（ステップＳ２０１）。エージェント２３１は、スペシャルファイルのｏｐｅｎに成功したか否かを判定する（ステップＳ２０２）。
　スペシャルファイルのｏｐｅｎに失敗したと判定された場合、エージェント２３１は、エラーと判定して処理を終了する。スペシャルファイルのｏｐｅｎに成功したと判定された場合、エージェント２３１は、ブロックのゲスト物理アドレスをゲスト仮想アドレスにマッピングするためにｍｍａｐを実行する（ステップＳ２０３）。エージェント２３１は、ｍｍａｐが成功したか否かを判定する（ステップＳ２０４）。
　ｍｍａｐが失敗したと判定された場合、エージェント２３１は、エラーと判定して処理を終了する。ｍｍａｐが成功したと判定された場合、エージェント２３１は、ｍｍａｐの実行結果として、アプリケーション２３２に対してゲスト仮想アドレスを返す（ステップＳ２０５）。
　なお、共有領域２２１をアンマップする場合、エージェント２３１は、ｍｕｎｍａｐを実行する。
　以上で説明したように、本実施例によれば、それぞれ独立した計算機リソースを有するホストＯＳ１（２００）及びホストＯＳ２（２１０）が稼働する計算機において、ホストＯＳ２が管理するＬＰＡＲ２２０上のアプリケーションと、ホストＯＳ１（２００）とが通信するための共有領域を確保することができる。
　したがって、独立した計算機リソースを使用するホストＯＳ１（２００）とホストＯＳ２上のアプリケーション２３２との間で通信等の処理が可能となる。
　なお、共有領域の使用方法は、ホストＯＳ１（２００）とホストＯＳ２上のアプリケーション２３２との間の通信に限定されるものではない。本発明を応用して、例えば、ホストＯＳ２とアプリケーション２３２との間の通信、又はホストＯＳ２とエージェント２３１との間の通信にも共有領域を使用することが可能である。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるプロセッサが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ等の広範囲のプログラム又はスクリプト言語で実装できる。
　さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、コンピュータが備えるプロセッサが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。
　上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

Claims (8)

  1. 　複数のオペレーティングシステムが稼働する計算機であって、
    　前記計算機は、計算機リソースとして、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるＩ／Ｏデバイスを備え、
    　前記計算機は、複数の記憶媒体を有するストレージ装置と接続し、
    　前記複数のオペレーティングシステムは、前記ストレージ装置に対するアクセスを制御する第１のオペレーティングシステム、及び少なくとも一つの仮想計算機を生成する第２のオペレーティングシステムを含み、
    　前記第１のオペレーティングシステム及び前記第２のオペレーティングシステムには、分割された前記計算機リソースが割り当てられ、
    　前記少なくとも一つの仮想計算機上では、アプリケーションを実行する第３のオペレーティングシステムが稼動し、
    　前記第２のオペレーティングシステムは、前記アプリケーションと前記第１のオペレーティングシステムとの間で通信するために用いられるメモリ領域である共有領域を管理する共有領域管理部を有し、
    　前記第３のオペレーティングシステムは、前記アプリケーションからの要求に応じて前記第２のオペレーティングシステムに対して前記共有領域の確保を要求し、前記アプリケーションに割り当てられる仮想的なメモリの位置を示すゲスト仮想アドレス空間に前記確保された共有領域をマッピングするエージェントを有することを特徴とする計算機。
  2. 　請求項１に記載の計算機であって、
    　前記第２のオペレーティングシステムは、前記共有領域を用いた前記第１のオペレーティングシステムと前記アプリケーションとの間の通信を制御する処理部を有し、
    　前記共有領域管理部は、
    　前記エージェントから前記共有領域の確保要求を受け付けた場合、所定のサイズの前記共有領域を確保し、
    　前記仮想計算機に含まれる論理メモリの物理的な位置を示すゲスト物理アドレス空間における、前記確保された共有領域にアクセスするための第１のアドレスを前記エージェントに通知し、
    　前記エージェントは、
    　前記第１のアドレスを用いて、前記ゲスト仮想アドレス空間に前記確保された共有領域をマッピングし、
    　前記ゲスト仮想アドレス空間にマッピングされた共有領域にアクセスするための第２のアドレスを前記アプリケーションに通知し、
    　前記アプリケーションは、前記第２のアドレスを受け付けた後、前記エージェントを介して前記処理部に前記共有領域を用いた処理の開始要求を送信し、
    　前記処理部は、
    　前記共有領域管理部から、前記第２のオペレーティングシステムが管理するホスト物理アドレス空間における、前記確保された共有領域にアクセスするための第３のアドレスを取得し、
    　前記第１のオペレーティングシステムに前記第３のアドレスを通知し、
    　前記第１のオペレーティングシステムは、前記第３のアドレスを用いて前記アプリケーションと通信することによって、前記共有領域を用いた処理を実行することを特徴とする計算機。
  3. 　請求項２に記載の計算機であって、
    　前記第２のオペレーティングシステムは、前記仮想計算機の起動時に、当該仮想計算機に割り当てられるメモリ領域の一部を前記共有領域として割り当てることを特徴とする計算機。
  4. 　請求項３に記載の計算機であって、
    　前記共有領域管理部は、
    　前記共有領域を複数のブロックに分割して管理し、
    　前記エージェントから前記共有領域の確保要求を受け付けた場合、少なくとも一つのブロックを前記アプリケーションに提供する共有領域として確保することを特徴とする計算機。
  5. 　複数のオペレーティングシステムが稼働する計算機におけるメモリ領域管理方法であって、
    　前記計算機は、計算機リソースとして、プロセッサ、前記プロセッサに接続されるメモリ、及び前記プロセッサに接続されるＩ／Ｏデバイスを備え、
    　前記計算機は、複数の記憶媒体を有するストレージ装置と接続し、
    　前記複数のオペレーティングシステムは、前記ストレージ装置に対するアクセスを制御する第１のオペレーティングシステム、及び少なくとも一つの仮想計算機を生成する第２のオペレーティングシステムを含み、
    　前記第１のオペレーティングシステム及び前記第２のオペレーティングシステムには、分割された前記計算機リソースが割り当てられ、
    　前記少なくとも一つの仮想計算機上では、アプリケーションを実行する第３のオペレーティングシステムが稼動し、
    　前記メモリ領域管理方法は、
    　前記アプリケーションが、前記第３のオペレーティングシステムを介して前記アプリケーションと前記第１のオペレーティングシステムとの間で通信するために用いるメモリ領域である共有領域の確保要求を発行する第１のステップと、
    　前記第２のオペレーティングシステムが、前記共有領域の確保要求に基づいて、前記共有領域を確保する第２のステップと、
    　前記第３のオペレーティングシステムが、前記アプリケーションに割り当てられる仮想的なメモリの位置を示すゲスト仮想アドレス空間に前記確保された共有領域をマッピングする第３のステップと、を含むことを特徴とするメモリ領域管理方法。
  6. 　請求項５に記載のメモリ領域管理方法であって、
    　前記第２のステップは、
    　所定サイズの前記共有領域を確保するステップと、
    　前記仮想計算機に含まれる論理メモリの物理的な位置を示すゲスト物理アドレス空間における、前記確保された共有領域にアクセスするための第１のアドレスを前記アプリケーションに通知するステップと、を含み、
    　前記第３のステップは、
    　前記第１のアドレスを用いて、前記ゲスト仮想アドレス空間に前記確保された共有領域をマッピングするステップと、
    　前記ゲスト仮想アドレス空間にマッピングされた共有領域にアクセスするための第２のアドレスを前記アプリケーションに通知するステップと、を含み、
    　前記メモリ領域管理方法は、
    　前記アプリケーションが、前記第２のアドレスを受け付けた後、前記第３のオペレーティングシステムを介して前記第２のオペレーティングシステムに前記共有領域を用いた処理の開始要求を送信するステップと、
    　前記第２のオペレーティングシステムが、前記処理の開始要求を受け付けた場合、前記第２のオペレーティングシステムが管理するホスト物理アドレス空間における、前記確保された共有領域にアクセスするための第３のアドレスを取得するステップと、
    　前記第２のオペレーティングシステムが、前記第１のオペレーティングシステムに前記第３のアドレスを通知するステップと、
    　前記第１のオペレーティングシステムが、前記第３のアドレスを用いて前記アプリケーションと通信することによって、前記共有領域を用いた処理を実行するステップと、を含むことを特徴とするメモリ領域管理方法。
  7. 　請求項６に記載のメモリ領域管理方法であって、
    　前記第２のオペレーティングシステムが、前記仮想計算機の起動時に、当該仮想計算機に割り当てられるメモリ領域の一部を前記共有領域として割り当てるステップを含むことを特徴とするメモリ領域管理方法。
  8. 　請求項７に記載のメモリ領域管理方法であって、
    　前記第２のオペレーティングシステムが、前記共有領域を複数のブロックに分割して管理するステップを含み、
    　前記第２のステップでは、少なくとも一つのブロックを前記アプリケーションに提供する共有領域として確保することを特徴とするメモリ領域管理方法。
PCT/JP2015/069628 2015-07-08 2015-07-08 計算機及びメモリ領域管理方法 Ceased WO2017006458A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/741,704 US10289564B2 (en) 2015-07-08 2015-07-08 Computer and memory region management method
PCT/JP2015/069628 WO2017006458A1 (ja) 2015-07-08 2015-07-08 計算機及びメモリ領域管理方法
JP2017527033A JP6458146B2 (ja) 2015-07-08 2015-07-08 計算機及びメモリ領域管理方法
CN201580081422.9A CN107710160B (zh) 2015-07-08 2015-07-08 计算机和存储区域管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/069628 WO2017006458A1 (ja) 2015-07-08 2015-07-08 計算機及びメモリ領域管理方法

Publications (1)

Publication Number Publication Date
WO2017006458A1 true WO2017006458A1 (ja) 2017-01-12

Family

ID=57685160

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/069628 Ceased WO2017006458A1 (ja) 2015-07-08 2015-07-08 計算機及びメモリ領域管理方法

Country Status (4)

Country Link
US (1) US10289564B2 (ja)
JP (1) JP6458146B2 (ja)
CN (1) CN107710160B (ja)
WO (1) WO2017006458A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018181840A1 (ja) * 2017-03-30 2018-10-04 日本電気株式会社 制御装置、制御システム、制御方法及びプログラム
EP3580650A4 (en) * 2017-03-20 2020-04-01 Huawei Technologies Co., Ltd. METHOD AND DEVICE FOR SECURE COMPUTER RESOURCES LOADED IN CONTAINERS
JPWO2023047436A1 (ja) * 2021-09-21 2023-03-30

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12339979B2 (en) 2016-03-07 2025-06-24 Crowdstrike, Inc. Hypervisor-based interception of memory and register accesses
US12248560B2 (en) * 2016-03-07 2025-03-11 Crowdstrike, Inc. Hypervisor-based redirection of system calls and interrupt-based task offloading
US10387681B2 (en) * 2017-03-20 2019-08-20 Huawei Technologies Co., Ltd. Methods and apparatus for controlling access to secure computing resources
JP7083717B2 (ja) * 2018-07-23 2022-06-13 ルネサスエレクトロニクス株式会社 半導体装置
WO2020214757A1 (en) 2019-04-17 2020-10-22 John Rankin Virtual memory pool within a network which is accessible from multiple platforms
US12436804B2 (en) 2019-05-28 2025-10-07 Micron Technology, Inc. Memory as a service for artificial neural network (ANN) applications
US11061819B2 (en) 2019-05-28 2021-07-13 Micron Technology, Inc. Distributed computing based on memory as a service
US11429390B2 (en) * 2019-12-06 2022-08-30 Rankin Labs, Llc High-level programming language which utilizes virtual memory
US11580019B2 (en) * 2020-04-17 2023-02-14 Microsoft Technology Licensing, Llc Computer memory management in computing devices
CN115669022B (zh) * 2020-05-21 2026-04-21 三星电子株式会社 电子设备提供基于测距的服务的方法和电子设备
CN112596642B (zh) * 2020-12-16 2022-06-07 维沃移动通信有限公司 数据共享方法、装置、设备和可读存储介质
CN113934509B (zh) 2021-09-02 2024-12-31 三星（中国）半导体有限公司 支持混合虚拟机管理器的系统和运行方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001243080A (ja) * 2000-03-02 2001-09-07 Hitachi Ltd 情報処理装置
JP2004258698A (ja) * 2003-02-24 2004-09-16 Hitachi Ltd マルチｏｓ計算機システムの制御方法
US20150046924A1 (en) * 2007-10-30 2015-02-12 Vmware, Inc. Transparent memory-mapped emulation of i/o calls

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3546678B2 (ja) 1997-09-12 2004-07-28 株式会社日立製作所 マルチｏｓ構成方法
US20050114595A1 (en) * 2003-11-26 2005-05-26 Veritas Operating Corporation System and method for emulating operating system metadata to provide cross-platform access to storage volumes
WO2009113394A1 (ja) 2008-03-14 2009-09-17 三菱電機株式会社 マルチオペレーティングシステム（ｏｓ）起動装置及びマルチｏｓ起動プログラム及び記録媒体及びマルチｏｓ起動方法
CN101477511B (zh) * 2008-12-31 2010-08-25 杭州华三通信技术有限公司 一种实现多操作系统共享存储介质的方法和装置
CN101847105B (zh) * 2009-03-26 2013-09-04 联想(北京)有限公司 一种计算机及多操作系统共享内存的方法
CN103034616B (zh) * 2012-12-07 2015-09-09 中国科学院声学研究所 一种多个操作系统访问存储介质的方法、计算机
CN107408052B (zh) * 2015-04-10 2021-04-16 谷歌有限责任公司 共享对象层级上的二进制转换的方法、系统和介质
US10146572B1 (en) * 2016-06-15 2018-12-04 Rockwell Collins, Inc. Resource management in hypervised computer systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001243080A (ja) * 2000-03-02 2001-09-07 Hitachi Ltd 情報処理装置
JP2004258698A (ja) * 2003-02-24 2004-09-16 Hitachi Ltd マルチｏｓ計算機システムの制御方法
US20150046924A1 (en) * 2007-10-30 2015-02-12 Vmware, Inc. Transparent memory-mapped emulation of i/o calls

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3580650A4 (en) * 2017-03-20 2020-04-01 Huawei Technologies Co., Ltd. METHOD AND DEVICE FOR SECURE COMPUTER RESOURCES LOADED IN CONTAINERS
WO2018181840A1 (ja) * 2017-03-30 2018-10-04 日本電気株式会社 制御装置、制御システム、制御方法及びプログラム
JP2018169978A (ja) * 2017-03-30 2018-11-01 日本電気株式会社 制御装置、制御システム、制御方法及びプログラム
JPWO2023047436A1 (ja) * 2021-09-21 2023-03-30
WO2023047436A1 (ja) * 2021-09-21 2023-03-30 日本電信電話株式会社 情報処理装置および情報処理方法
JP7684603B2 (ja) 2021-09-21 2025-05-28 日本電信電話株式会社 情報処理装置および情報処理方法

Also Published As

Publication number Publication date
JP6458146B2 (ja) 2019-01-23
US10289564B2 (en) 2019-05-14
JPWO2017006458A1 (ja) 2018-05-10
US20180203805A1 (en) 2018-07-19
CN107710160B (zh) 2021-06-22
CN107710160A (zh) 2018-02-16

Similar Documents

Publication Publication Date Title
JP6458146B2 (ja) 計算機及びメモリ領域管理方法
US12405816B2 (en) Virtual machine live migration method and communications device
US9606745B2 (en) Storage system and method for allocating resource
US8365167B2 (en) Provisioning storage-optimized virtual machines within a virtual desktop environment
JP4487920B2 (ja) ブート制御方法および計算機システム並びにその処理プログラム
US9146766B2 (en) Consistent unmapping of application data in presence of concurrent, unquiesced writers and readers
US8775696B2 (en) Storage area network access for virtual machines
JP6165964B2 (ja) 計算機
US20120246644A1 (en) Virtual computer system and controlling method of virtual computer
JP6316895B2 (ja) ホスト側フラッシュストレージデバイスの容量を仮想マシンに利用可能にする技術
JP2010257274A (ja) 仮想化環境におけるストレージ管理システム及びストレージ管理方法
US11593170B2 (en) Flexible reverse ballooning for nested virtual machines
US20220382597A1 (en) Methods and apparatus to allocate hardware in virtualized computing architectures
JP5966466B2 (ja) バックアップ制御方法、および情報処理装置
WO2015052836A1 (ja) ストレージ装置及びフェールオーバ方法
WO2015122007A1 (ja) 計算機、及び、ハイパバイザによる資源スケジューリング方法
US7500051B2 (en) Migration of partitioned persistent disk cache from one host to another
WO2016110951A1 (ja) 計算機システム、ライセンス管理方法、及び、管理計算機
JP2013206454A (ja) 情報処理装置、装置管理方法および装置管理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15897720

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017527033

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15741704

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15897720

Country of ref document: EP

Kind code of ref document: A1