WO2014174580A1 - 情報処理装置、方法、及びプログラム - Google Patents

情報処理装置、方法、及びプログラム Download PDF

Info

Publication number
WO2014174580A1
WO2014174580A1 PCT/JP2013/061805 JP2013061805W WO2014174580A1 WO 2014174580 A1 WO2014174580 A1 WO 2014174580A1 JP 2013061805 W JP2013061805 W JP 2013061805W WO 2014174580 A1 WO2014174580 A1 WO 2014174580A1
Authority
WO
WIPO (PCT)
Prior art keywords
dmar
guest
vmm
virtual machine
virtual
Prior art date
Application number
PCT/JP2013/061805
Other languages
English (en)
French (fr)
Inventor
広隆 福島
Original Assignee
富士通株式会社
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 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2015513387A priority Critical patent/JP5962853B2/ja
Priority to PCT/JP2013/061805 priority patent/WO2014174580A1/ja
Publication of WO2014174580A1 publication Critical patent/WO2014174580A1/ja
Priority to US14/883,679 priority patent/US10162657B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/1081—Address translation for peripheral access to main memory, e.g. direct memory access [DMA]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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

Definitions

  • the disclosed technology relates to an information processing apparatus, an information processing method, and an information processing program.
  • nested virtualization technology has been proposed as a virtualization technology for constructing a virtual computer (virtual machine) on a computer.
  • the nested virtualization technique is a virtualization technique for moving a virtual machine on a virtual machine.
  • BIOS Basic Input Input Output System
  • BIOS starts up a virtual machine.
  • Xen registered trademark
  • the virtual machine monitor that constructs the virtual machine basically performs processing by software, but there is also a virtual machine monitor that uses a virtualization support mechanism that takes part of the processing of the virtual machine monitor by hardware. To do.
  • a technology has been proposed in which a virtualization support mechanism by hardware is virtualized and provided for the second layer virtualization in the above-mentioned nested virtualization technology.
  • a virtualization technique in which a CPU having a virtualization support mechanism operates in a normal mode and a mode that provides a virtualization support mechanism has been proposed.
  • a host VMM Virtual Machine Monitor
  • the CPU operation mode is switched between a host mode in which the host VMM operates and a user mode in which the guest VMM or user program operates.
  • the host VMM emulates the guest VMM and guest OS commands under predetermined conditions.
  • the virtual CPU assigned to the virtual machine on which the guest OS runs provides the guest OS with a virtualization support mechanism.
  • DMA Direct Memory Access
  • I / O Input / Output
  • DMAR DMA Remapping
  • the hardware that provides this DMAR virtualization support mechanism is called DMAR-HW (hardware).
  • a hardware conversion mechanism that performs DMA address conversion of input / output devices such as the conventional DMAR-HW supports only one-level virtualization. Therefore, there is a problem that the virtual machine monitor and guest program higher than the second layer in the nested virtualization technology cannot be used.
  • One aspect of the disclosed technology is to speed up virtualization when providing a hardware translation mechanism for performing DMA address translation by an input / output device to a guest program in a nested virtualization environment. is there.
  • the disclosed technology includes a specifying unit that specifies the cause of the transition from the non-privileged mode to the privileged mode that occurs in the processing of the guest program in the nested virtual environment.
  • the nested virtualization environment is a virtualization environment in which an upper virtual machine is constructed by an upper virtual machine monitor that operates on a virtual machine constructed by a first layer virtual machine monitor.
  • the virtual machine monitor in the first layer operates in a privileged mode, and the upper virtual machine monitor and the guest program on the upper virtual machine operate in a non-privileged mode.
  • the disclosed technology includes a setting unit that sets a conversion table used in the conversion mechanism when the factor specified by the specifying unit is setting or updating of a virtual conversion table.
  • the virtual conversion table is provided to the guest program by virtualizing a hardware conversion mechanism using a conversion table in which DMA address conversion by an input / output device assigned to the upper virtual machine is set Used in.
  • the setting unit uses the virtual conversion table and the conversion table used in the conversion mechanism based on the correspondence between the guest memory space in which the guest program operates and the host memory space in which the first-layer virtual machine monitor operates. Set.
  • the disclosed technology can speed up virtualization when providing a hardware translation mechanism that performs DMA address translation by an input / output device to a guest program in a nested virtualization environment. It has the effect.
  • DMAR-HW It is the schematic which shows the address translation by DMAR-HW. It is a figure which shows an example of a DMAR table. It is a block diagram which shows the outline of virtualization of DMAR-HW. It is a figure which shows the relationship of the DMAR table in HPA and GPA. It is a figure for demonstrating the update of a DMAR table. It is a block diagram which shows the outline of the virtualization support mechanism of CPU in a nested virtualization structure. It is a block diagram which shows the outline of a comparative example. It is the schematic which shows the memory structure of a comparative example. It is a functional block diagram of VMM in a comparative example.
  • 14 is a flowchart showing processing of a VM-Exit handler in the third embodiment.
  • 14 is a flowchart illustrating VM-Exit processing from the VMM 120 in the third embodiment.
  • 14 is a flowchart illustrating a VM-Exit process from the VMM in the third embodiment. It is a flowchart which shows the DMAR virtualization process in 3rd Embodiment. It is a figure for demonstrating the transition between the non-privileged mode and privilege mode in 3rd Embodiment.
  • a guest OS (Operating System) on a virtual machine (VM) constructed by a virtual machine monitor (VMM) is used as an I / O (Input / Output) device to be used. Allocate resources.
  • I / O device accesses the allocated memory resource, it is necessary to convert the address in the guest memory space (GPA: Guest Physical Address) to the address in the host memory space (HPA: Host Physical Address). is there. This conversion is performed by the DMAR, and the hardware that performs the DMAR is called DMAR-HW.
  • the 0 to 2 GB area of the guest memory space is allocated to the I / O devices 801 and 802, and the 0 to 2 GB area of the guest memory space is assigned to 4 GB to 4 GB of the host memory space. Assume that it corresponds to a 6 GB area.
  • the I / O device 801 or 802 accesses an address in the 0 to 2 GB area of the guest memory space. Then, the guest memory space address (GPA) accessed by the I / O device is converted by the DMAR-HW 200 into the host memory space address (HPA).
  • GPSA guest memory space address
  • HPA host memory space address
  • DMAR-HW 200 In order to convert the address accessed by the I / O device from GPA to HPA, it is necessary to set in the DMAR-HW 200 a conversion table (DAR table) indicating what conversion is to be performed. This conversion table is created on the memory, and the head address is set in the register of the DMAR-HW 200.
  • DAR table conversion table
  • FIG. 2 shows a configuration example of the DMAR table 500 in VT-d, which is a virtualization support mechanism based on Intel (registered trademark) DMAR-HW.
  • the register of the DMAR-HW 200 is mapped to a specific area on the memory.
  • the entry corresponding to the I / O device in the DMAR table 500 includes a bus number (Bus), a device number (Dev), and a function number (Fun).
  • the DMAR table 500 has a hierarchical structure.
  • the bus entry numbers of the I / O devices are classified by the route entry table 500A of the first hierarchy, and the device numbers and function numbers of the I / O devices are given by the context entry table 500B of the second hierarchy. Classify.
  • the third and subsequent layers are called an address conversion table 500C, and a conversion method for converting GPA accessed by an I / O device into HPA is set.
  • the address conversion table can be shared and used. That is, the DMAR table 500 defines an association between an entry corresponding to an I / O device and a GPA-HPA conversion method.
  • the DMAR-HW can directly allocate an I / O device to the guest OS operating on the VM by converting the GPA to the HPA using such a conversion table.
  • the DMAR-HW can also be used for a normal OS other than the VMM.
  • a DMAR table may be set so that DMA cannot be performed from the I / O device to that area.
  • the VMM needs to virtualize the DMAR-HW and provide it to the guest OS so that the guest OS operating on the VM can use the DMAR-HW.
  • a CPU virtualization support mechanism such as Intel (registered trademark) VT-x can be used.
  • FIG. 3 shows an example of DMAR-HW virtualization implemented by the information processing apparatus 151.
  • the information processing apparatus 151 includes a CPU 400, which is a hardware resource, a memory 300, a DMAR-HW 200, and I / O devices 801 and 802.
  • the CPU 400 includes a hardware virtualization support mechanism 490 such as Intel (registered trademark) VT-x.
  • Intel registered trademark
  • the VMM 110 includes a VM-Exit handler 10 and a DMAR virtualization unit 11.
  • the DMAR virtualization unit 11 virtualizes the DMAR-HW 200 and provides it to the VM 111, which is shown to the guest OS 140 as the v (virtual) DMAR-HW 211.
  • the VM 112 is provided with the vDMAR-HW 212.
  • the DMAR virtualization unit 11 monitors access to the register of the vDMAR-HW 211 by the guest OS 140. Since the register of the DMAR-HW 200 is mapped to a specific address in the memory space, the DMAR virtualization unit 11 shows the guest OS 140 so that the register of the vDMAR-HW 211 is also mapped to the same position.
  • the guest OS 140 When the guest OS 140 accesses the mapped register, it sets the virtualization support mechanism 490 of the CPU 400 so that an exception occurs.
  • the VM Exit handler 10 specifies the cause when an exception occurs, and calls the DMAR virtualization unit 11 when the guest OS 140 accesses the mapped register.
  • the DMAR virtualization unit 11 identifies the location of the DMAR table 510 created by the guest OS 140 from the address that the guest OS 140 tried to set in the vDAR-HW 211 register.
  • the DMAR table 510 is a DMAR table that is set in the vDAR-HW 211 when the guest OS 140 initializes the I / O device assigned by the VMM 110.
  • the DMAR table 510 is created on the GPA by the guest OS 140 and includes settings related to the area on the GPA space allocated to the I / O device.
  • the VMM 110 creates a DMAR table 501 in which the contents of the DMAR table 510 are converted into the HPA space based on the address conversion method from the GPA space to the HPA space managed by the VMM 110.
  • a DMAR table 500 is set in advance. For example, it is assumed that an I / O device 801 is allocated to the VM 111 and an I / O device 802 is allocated to the VM 112.
  • the DMAR table 500 includes a setting for converting the DMA of the I / O device 801 allocated to the VM 111 and a setting for converting the DMA of the I / O device 802 allocated to the VM 112.
  • the DMAR virtualization unit 11 updates the setting regarding the I / O device 801 allocated to the VM 111 on which the guest OS 140 operates in the DMAR table 500 with the contents of the DMAR table 501. A method for updating the DMAR table will be described later.
  • the DMAR virtualization unit 11 uses the virtualization support mechanism 490 of the CPU 400 to set the area where the DMAR table 510 is placed in WP (Write Protect). This is for detecting an update of the DMAR table 510 by the guest OS 140. When an update of the DMAR table 510 is detected, emulation can be performed so that the updated contents are reflected in the DMAR table 501.
  • WP Write Protect
  • FIG. 4 shows the relationship of the DMAR table between HPA and GPA in the virtualization of DMAR-HW shown in FIG.
  • HPA address ranges 4 GB to 6 GB are assigned as GPA 0 GB to 2 GB.
  • the DMAR table 510 created on the GPA by the guest OS 140 includes a setting that the address range 1 GB to 2 GB of the GPA is an area allocated to the I / O device 801.
  • the DMAR table 501 is obtained by converting the DMAR table 510 onto the HPA.
  • the DMAR table 501 includes a setting that the HPA address range 5 GB to 6 GB is an area allocated to the I / O device 801. Based on the DMAR table 501 converted in this manner, the preset (initial state) DMAR table 500 is updated.
  • FIG. 5 shows an example of updating the DMAR table 500.
  • entries corresponding to the I / O device 801 are a bus number (Bus) N, a device number (Dev) i, and a function number (Fun) j.
  • the bus number N corresponds to the root entry N of the root entry table 500A
  • the device number i and the function number j correspond to the context entry M of the context entry table 500B corresponding to the root entry N.
  • this entry refers to the address translation table 500C1.
  • the address conversion table 500C2 is a part of the DMAR table 501 and the setting that the guest OS 140 converts to the I / O device 801 is converted to the HPA.
  • the update of the DMAR table 500 is performed by changing the reference of the entry of the root entry N and the context entry M, that is, the entry of the I / O device 800, from the address translation table 500C1 to the address translation table 500C2.
  • VT-x which is a virtualization support mechanism for an Intel (registered trademark) CPU
  • two operation modes a privileged mode and a non-privileged mode
  • the functions that can be used are limited, and if an unauthorized process such as execution of a privileged instruction is performed, an exception occurs and the privileged mode is entered.
  • the CPU is in the privileged mode, it is possible to execute all privileged instructions and to monitor and catch exceptions that occur in the non-privileged mode.
  • the transition of the CPU operation mode from the privileged mode to the non-privileged mode is referred to as VM-Entry, and the transition from the non-privileged mode to the privileged mode is referred to as VM-Exit.
  • FIG. 6 shows an example of nested virtualization implemented by the information processing apparatus 152.
  • the same parts as those in the prior art DMAR-HW virtualization example shown in FIG. 3 are denoted by the same reference numerals, and detailed description thereof is omitted.
  • the information processing apparatus 152 includes a CPU 400 and a memory 300 which are hardware resources.
  • the first layer VMM 110 is operated to construct the first layer VM 111.
  • the second layer VMM 120 is operated on the VM 111, the second layer VM 121 is constructed, and the guest OS 140 is operated on the VM 121.
  • the VMM 110 operates in the privileged mode, and the VMM 120 and the guest OS 140 operate in the non-privileged mode.
  • the host memory space where the VMM 110 operates is HPA
  • the guest memory space where the VMM 120 operates is GPA1
  • the guest memory space where the guest OS 140 operates is GPA2.
  • a v (virtual) memory 310 and a v (virtual) CPU 410 are allocated to the VM 111. Further, a v (virtual) memory 320 and a v (virtual) CPU 420 are allocated to the VM 121.
  • the CPU 400 includes a hardware virtualization support mechanism 490 such as Intel (registered trademark) VT-x.
  • Intel registered trademark
  • VT-x an area for holding the CPU state called VMCS (Virtual Machine Control Structure) is created on the memory, and the VMCS address is referred to the virtualization support mechanism 490 so that the CPU 400 state (privileged mode, non-privileged) Mode).
  • VMCS Virtual Machine Control Structure
  • the VMCS 700 holds control information such as a host state holding unit 701 that holds a state of a host that operates in a privileged mode, a guest state holding unit 702 that holds a state of a guest that operates in a non-privileged mode, and other settings and states.
  • the control information holding unit 703 is provided.
  • control information holding unit 703 is configured to specify, for example, what factors cause VM-Exit to be performed, identification of factors when actual VM-Exit is performed, and EPT (Extended) that performs GPA-HPA conversion of the CPU described later. Set Page Table).
  • a v (virtual) VMCS 710 for holding the state of the vCPU 410 assigned to the VM 111.
  • the vVMCS 710 is provided in the v memory 310 allocated to the VM 111, and includes a host state holding unit 711, a guest state holding unit 712, and a control information holding unit 713, similar to the VMCS 700.
  • the host state holding unit 711 of the vVMCS 710 stores the state of the vCPU 410 operating the VMM 120
  • the guest state holding unit 712 stores the state of the vCPU 420 operating the guest OS 140.
  • a VMCS-C (Copy) 600 which is a save area of the VMCS 700, is also placed.
  • the VMCS-C 600 also includes a host state holding unit 601, a guest state holding unit 602, and a control information holding unit 603. How to use VMCS-C600 will be described later.
  • a VMREAD instruction or a VMWRITE instruction which is a privileged instruction is used.
  • the VMM 120 in the second layer wants to set the guest state holding unit 712 of the vVMCS 710 to operate the guest OS 140, the VMWRITE instruction is executed.
  • the VMMM 120 operating in the non-privileged mode tries to execute the VMWRITE instruction, which is a privileged instruction, an exception occurs, and the VM-Exit is performed, and the process proceeds to the VMM 110.
  • the VMM 110 specifies that the VM-Exit factor (hereinafter referred to as “VM-Exit factor”) is the execution of the VMWRITE instruction.
  • VM-Exit factor the VM-Exit factor
  • the VMM 120 executes a VM-Entry instruction in order to transfer the process to the guest OS 140.
  • the VMM 120 operating in the non-privileged mode tries to execute the VM-Entry instruction that is a privileged instruction, an exception is generated and the VMM 110 is VM-Exited.
  • the VMM 110 When the VMM 110 specifies that the VM-Exit factor is execution of the VM-Entry instruction, the VMM 110 copies the state of the vCPU 410 held in the guest state holding unit 702 of the VMCS 700 to the host state holding unit 711 of the vVMCS 710. Then, the state of the vCPU 420 held in the guest state holding unit 712 of the vVMCS 710 is set in the guest state holding unit 702 of the VMCS 700.
  • the setting for monitoring and controlling the VMM 120 held in the control information holding unit 703 of the VMCS 700 is saved in the control information holding unit 603 of the VMCS-C 600.
  • the setting for monitoring and controlling the guest OS 140 is performed in the control information holding unit 703 of the VMCS 700.
  • This setting includes a setting for the VMM 110 held in the control information holding unit 603 of the VMCS-C 600 to monitor and control the VMM 120, and a VMM 120 held in the control information holding unit 713 of the vVMCS 710 monitor and control the guest OS 140. Created from with settings for.
  • the VMM 110 virtualizes a specific hardware resource and shows it to the VMM 120.
  • the VMM 110 sets the control information holding unit 703 of the VMCS 700 so as to perform VM-Exit when the VMM 120 accesses the hardware resource.
  • the VMM 120 is assumed to show the guest OS 140 as it is without virtualizing this hardware resource.
  • the control information holding unit 713 of the vVMCS 710 is not set to perform VM-Exit even when the guest OS 140 accesses this hardware resource.
  • the VMM 110 actually monitors and controls the guest OS 140, when the guest OS 140 accesses this hardware resource, it needs to be set to perform VM-Exit. Therefore, the setting for the VMM 110 to monitor and control the guest OS 140 is created from the setting for the VMM 110 to monitor and control the VMM 120 and the setting for the VMM 120 to monitor and control the guest OS 140.
  • the VMM 110 executes a VM-Entry instruction and moves the processing to the guest OS 140.
  • the process returns to the VMM 110.
  • the VMM 110 identifies the VM-Exit factor, and collates it with the VM-Exit factor set in the control information holding unit 713 of the vVMCS 710 as the VM-Exit factor processed by the VMM 120. If it is a VM-Exit factor to be processed by the VMM 120, the processing is shifted to the VMM 120, and the VMM 120 is caused to process an exception (processing according to the VM-Exit factor).
  • the state of the vCPU 420 held in the guest state holding unit 702 is copied to the guest state holding unit 712 of the vVMCS 710. Then, the state of the vCPU 410 held in the host state holding unit 711 of the vVMCS 710 is set in the guest state holding unit 702 of the VMCS 700. The settings saved in the control information holding unit 603 and information regarding the VM-Exit are set in the control information holding unit 703 of the VMCS 700. Finally, the VM-Entry instruction is executed, and the process is transferred to the VMM 120.
  • the VMM 120 determines that the VM-Exit processing from the guest OS 140 has been transferred by the VM-Entry from the VMM 110, and performs processing according to the VM-Exit factor.
  • the vVMCS 710 is set to return the process to the guest OS 140 and the VM-Entry instruction is executed. As described above, these are performed by emulation by the VMM 110.
  • the state transition between the VMM 120 in the second layer and the guest OS 140 is performed once via the VMM 110 in the first layer.
  • the CPU virtualization support mechanism is provided with a GPA-HPA conversion function for memory access by the CPU.
  • the GPA-HPA conversion of the CPU is performed using a conversion table, similar to DMAR.
  • this conversion table can also set memory attributes such as setting a specific area of GPA to WP.
  • this conversion table is called an EPT (Extended Page Table).
  • EPT Extended Page Table
  • an EPT 901 that is a conversion table between the address GPA 1 of the guest memory space of the VM 111 and the address HPA of the host memory space is created and set in the control information holding unit 703 of the VMCS 700.
  • an EPT 912 that is a conversion table between the address GPA 2 of the guest memory space of the VM 121 and the guest memory space GPA 1 of the VMM 120 is created and set in the control information holding unit 713 of the vVMCS 710.
  • the VMM 110 can create an EPT 902 that is a GPA2-HPA conversion table from an EPT 901 that is a GPA1-HPA conversion table and an EPT 912 that is a GPA2-GPA1 conversion table. That is, the EPT 902 is a conversion table set in the control information holding unit 703 when VM-Entry from the VMM 110 to the guest OS 140 is performed.
  • FIG. 7 shows an example of DMAR-HW nested virtualization in the case where the conventional nested virtualization and DMAR-HW virtualization are combined as they are.
  • the same parts as those of the prior art DMAR-HW virtualization shown in FIG. 3 and the nested virtualization example shown in FIG. 6 are denoted by the same reference numerals, and detailed description thereof is omitted.
  • the configuration shown in FIG. 7 is referred to as a comparative example.
  • the first-layer VMM 110 is operated to construct the first-layer VMs 111 and 112. Further, the second layer VMM 120 is operated on the VM 111, the second layer VM 121 is constructed, and the guest OS 140 is operated on the VM 121.
  • the host memory space where the VMM 110 operates is HPA
  • the guest memory space where the VMM 120 operates is GPA1
  • the guest memory space where the guest OS 140 operates is GPA2.
  • the VM 111 is provided with the vDMAR-HW 211 and is assigned with the v memory 311 and the vCPU 410. Further, the VM 121 is provided with a vDMAR-HW 221 and assigned with a v memory 321 and a vCPU 420.
  • FIG. 8 shows an example of the configuration of the memory 300 in the configuration of FIG.
  • the area allocated to the v memory 311 of the memory 300 includes an area allocated to the v memory 321.
  • the area allocated to the v memory 321 stores the GPA2-based DMAR table 520 created by the guest OS 140.
  • the DMAR table 512 obtained by converting the DMAR table 520 into the GPA1 standard, and the GPA1 standard DMAR table 510 created by the VMM 120 are stored.
  • a vVMCS 710 that holds the state of the vCPU 410 and an EPT 912 that is a conversion table between GPA 2 and GPA 1 are stored.
  • the memory 300 stores a DMAR table 500 created by the VMM 110 based on the HPA standard, a DMAR table 501 obtained by converting the DMAR table 510 into the HPA standard, and a DMAR table 502 obtained by converting the DMAR table 520 into the HPA standard. Further, the memory 300 stores VMCS 700 that holds the state of the CPU 400 and VMCS-C 600 that saves the state of the VMCS 700. The memory 300 also stores an EPT 901 that is a conversion table between GPA 1 and HPA, and an EPT 902 that is a conversion table between GPA 2 and HPA.
  • the VMM 110 includes a VM-Exit handler 10 and a DMAR virtualization unit 11.
  • the DMAR virtualization unit 11 includes a GPA1 DMAR table acquisition unit 12, a GPA1-HPA conversion unit 13, a WP setting unit 14, a DMAR table creation unit 15, and a host DMAR table update unit 16.
  • the VMM 120 also includes a VM-Exit handler 20 and a DMAR virtualization function 21, and provides the same functions as the VM-Exit handler 10 and the DMAR virtualization unit 11 of the VMM 110.
  • the VM-Exit handler 10 captures the VM-Exit from the guest OS 140 or the VMM 120, specifies the VM-Exit factor, and performs processing according to the VM-Exit factor.
  • the process according to the VM-Exit factor is, for example, setting for the VMCS when performing VM-Entry to the guest OS 140 or the VMM 120.
  • the VMM 120 changes the EPT 912 so that the VMM 120 sets the area of the DMAR table 520 created by the guest OS 140 in the WP
  • the VM-Exit handler 10 reflects the changed contents on the EPT 902.
  • the GPA1 DMAR table acquisition unit 12 acquires the DMAR table 510 and the DMAR table 512 managed by the VMM 120.
  • the GPA1-HPA conversion unit 13 converts GPA1 into HPA.
  • the WP setting unit 14 sets the area of the DMAR tables 510 and 512 to WP.
  • the DMAR table creation unit 15 creates a DMAR table obtained by performing GPA1-HPA conversion on the DMAR table acquired by the GPA1 DMAR table acquisition unit 12.
  • the host DMAR table update unit 16 updates the DMAR table 500 with the contents of the DMAR table created by the DMAR table creation unit 15.
  • FIG. 10 shows a processing flow by the VM-Exit handler 10.
  • FIG. 11 shows a process (1) flow for each VM-Exit factor in the process flow by the VM-Exit handler 10.
  • FIG. 12 shows a DMAR virtualization processing flow by the DMAR virtualization unit 11.
  • step S1 of the processing flow of the VM-Exit handler 10 shown in FIG. 10 the VM-Exit handler 10 sends the VM-Exit factor from the guest OS 140 or the VMM 120 to the control information holding unit 703 of the VMCS 700 in the virtualization support mechanism 490. Is specified by referring to the VM-Exit factor stored automatically. For example, when the guest OS 140 sets the DMAR table 520 in the vDMAR-HW 221, the guest OS 140 accesses the address to which the register of the vDMAR-HW 221 is mapped. The EPT 902 is set in advance so that an exception occurs when accessing this address.
  • the address causing the exception is obtained from the information stored in the control information holding unit 703 of the VMCS 700, and this address is the vDMR-HW221. If the register matches the mapped address, it can be determined that “setting to vDMAR-HW 221”.
  • step S 2 the VM-Exit handler 10 determines whether the captured VM-Exit is a VM-Exit from the guest OS 140 or a VM-Exit from the VMM 120. In the case of VM-Exit of the guest OS 140, the process proceeds to step S55, and in the case of VM-Exit from the VMM 120, the process proceeds to step S10.
  • step S55 the VM-Exit handler 10 determines whether the processing according to the VM-Exit factor is performed as it is by the VMM 110 or left to the VMM 120, that is, the processing destination. This determination is performed by previously setting a VM-Exit factor to be processed by the VMM 120 in the control information holding unit 713 of the vVMCS 710 and referring to this setting.
  • the VMM Exit factor is processed by the VMM 110
  • the process proceeds to step S20.
  • the VMM Exit factor is processed by the VMM 120, the process proceeds to step S61.
  • step S61 the VM-Exit handler 10 performs various settings in the VMCS for transferring processing to the VMM 120.
  • step S 62 the VM-Exit handler 10 performs VM-Entry to the VMM 120 in order to transfer the processing to the VMM 120.
  • step S20 the VM-Exit handler 10 executes the process (2) for each VM-Exit factor.
  • the process (2) for each VM-Exit factor is a process to be performed by the VMM 110, such as reading / writing a value to / from a register and executing an instruction.
  • the process (2) for each VM-Exit factor is completed, the process proceeds to step S22, and the VM-Exit handler 10 VM-Entry to the guest OS 140 in order to return the process to the guest OS 140.
  • step S10 the VM-Exit handler 10 determines whether the VM-Exit factor specified in step S1 is a VM-Entry instruction. If the VM-Exit factor is a VM-Entry instruction, the process proceeds to step S21, and the VM-Exit handler 10 performs various settings for moving the process to the guest OS 140 in the VMCS. Next, in step S ⁇ b> 22, the VM-Exit handler 10 performs VM-Entry to the guest OS 140 in order to transfer the processing to the guest OS 140.
  • step S10 determines in step S10 that the VM-Exit factor is not a VM-Entry instruction
  • the process proceeds to step S30, and the processing (1) for each VM-Exit factor shown in FIG. Execute.
  • the process proceeds to step S100, and when it is not the setting to vDMAR-HW 211, the process proceeds to step S32.
  • step S32 the VM-Exit handler 10 determines whether or not the DMAR table 510 in which the VM-Exit factor is set to WP is updated. If the VM-Exit factor is updating the DMAR table 510 with WP set, the process proceeds to step S100, and if not updating the DMAR table 510 with WP set, the process proceeds to step S33.
  • step S100 the DMAR virtualization unit 11 executes the DMAR virtualization process shown in FIG.
  • step S101 of the DMAR virtualization process shown in FIG. 12 the VM-Exit handler 10 determines whether the VM-Exit factor is set in the vDMAR-HW 211.
  • the process proceeds to step S102, and when the VM-Exit factor is the update of the DMAR table 510 in which the WP is set, the process proceeds to step S111.
  • step S102 the GPA1 DMAR table acquisition unit 12 acquires the DMAR table 510 created by the VMM 120.
  • the DMAR table 510 is created based on the GPA1 standard. Therefore, in the next step S103, the DMAR table creation unit 15 creates a DMAR table 501 obtained by converting the GPA1-based DMAR table 510 into the HPA standard using the GPA1-HPA conversion unit 13.
  • step S ⁇ b> 104 the host DMAR table update unit 16 updates the setting for the I / O device 801 in the DMAR table 500 with the contents of the DMAR table 501.
  • the WP setting unit 14 reflects the WP setting of the memory area in which the DMAR table 510 is stored in the EPT 901 that performs the GPA1-HPA conversion of the CPU 400 so that the update of the DMAR table 510 by the VMM 120 can be detected.
  • the process returns to the process (1) for each VM-Exit factor shown in FIG.
  • step S111 the GPA1 DMAR table acquisition unit 12 acquires the DMAR table 512 created by the VMM 120.
  • the DMAR table 512 is created based on the GPA1 standard. Therefore, in the next step S112, the DMAR table creation unit 15 creates the DMAR table 502 obtained by converting the GPA1-based DMAR table 512 into the HPA standard using the GPA1-HPA conversion unit 13.
  • step S113 the host DMAR table update unit 16 updates the setting for the I / O device 801 in the DMAR table 500 with the contents of the DMAR table 502.
  • step S114 the WP setting unit 14 sets the WP setting of the memory area in which the DMAR table 512 is stored to the EPT 901 that performs the GPA1-HPA conversion of the CPU 400 so that the update of the DMAR table 512 by the VMM 120 can be detected. reflect.
  • the process returns to the process (1) for each VM-Exit factor shown in FIG.
  • step S32 If a negative determination is made in step S32, the process proceeds to step S33, the VM-Exit handler 10 executes a process according to the VM-Exit factor, and returns to the process by the VM-Exit handler 10 shown in FIG. To do.
  • FIG. 13 shows the transition between the non-privileged mode and the privileged mode in the DMAR-HW nested virtualization process.
  • an I / O device 801 is assigned to the guest OS 140, and the guest OS 140 performs settings for the I / O device 801 in the vDAR-HW 221.
  • the VM-Exit from the non-privileged mode to the privileged mode is indicated by a one-dot chain line arrow
  • the VM-Entry from the privileged mode to the non-privileged mode is indicated by a two-dot chain line arrow.
  • step S500 of FIG. 13 when the guest OS 140 accesses the register of the vDMAR-HW 221 to set the DMAR table 520 in the vDMAR-HW 221, it performs a VM-Exit to the VMM 110. Originally, it is desired to transfer the processing to the VMM 120 of the second layer that manages the vDMAR-HW 221. However, since the guest OS 140 and the VMM 120 are both in the non-privileged mode and VM-Exit cannot be directly performed, the VM- Exit.
  • step S501 the VM-Exit handler 10 specifies a VM-Exit factor.
  • the VM-Exit factor is the setting of the vDAR-HW 221 by the guest OS 140, which is originally a process of the VMM 120, so the process moves to the VMM 120 in step S502.
  • Steps S501-> S502 correspond to steps S1-> S2-> S55-> S61-> S62 in FIG.
  • step S503 the VM-Exit handler 20 of the VMM 120 specifies that the VM-Exit factor is the setting for the vDAR-HW 221 by the guest OS 140.
  • step S504 the DMAR virtualization function 21 of the VMM 120 creates a DMAR table 512 obtained by converting the DMAR table 520 created based on the GPA2 space on the basis of the GPA1 space.
  • step S505 the DMAR virtualization function 21 updates the DMAR table 510 with the contents of the DMAR table 512. Since the WP is set in the memory area in which the DMAR table 510 is stored, an exception occurs due to the update of the DMAR table 510 and the VMM 110 is VM-Exited.
  • step S506 the VM-Exit handler 10 specifies that the VM-Exit factor is an update of the DMAR table 510 set with WP.
  • step S507 the GPA1 DMAR table acquisition unit 12 acquires the DMAR table 512.
  • the DMAR table creation unit 15 uses the GPA1-HPA conversion unit 13 to create the DMAR table 502 obtained by converting the GPA1-standard DMAR table 512 into the HPA standard.
  • step S508 the host DMAR table update unit 16 updates the DMAR table 500 with the contents of the DMAR table 502.
  • step S509 the WP setting unit 14 sets the memory area in which the DMAR table 512 is stored in the WP.
  • step S ⁇ b> 510 the VM-Exit handler 10 performs VM-Entry to the VMM 120 in order to transfer the processing to the VMM 120.
  • Steps S506 ⁇ S507 ⁇ S508 ⁇ S509 ⁇ S510 are steps S1 ⁇ S2 ⁇ S10 ⁇ S30 ⁇ S31 ⁇ S32 ⁇ S100 ⁇ S101 ⁇ S111 ⁇ S112 ⁇ S113 ⁇ S114 of FIG. It corresponds to.
  • step S511 the VMM 120 sets the WP of the memory area in which the DMAR table 520 created by the guest OS 140 is stored in the EPT 912 that performs the GPA2-GPA1 conversion of the vCPU 410.
  • step S 512 the VMM 120 performs setting for the VM-Entry to the guest OS 140 to the vVMCS 710 of the vCPU 410. Since the setting to the vVMCS 710 involves execution of the privileged command VMWRITE or VMREAD, the VMM 110 is VM-Exited.
  • step S513 the VM-Exit handler 10 specifies the VM-Exit factor as VMWRITE or VMREAD to the vVMCS 710.
  • step S514 the VM-Exit handler 10 sets the vVMCS 710 and the EPT 902.
  • step S ⁇ b> 515 the VM-Exit handler 10 performs VM-Entry to the VMM 120 in order to transfer the processing to the VMM 120.
  • the VM-Exit and the VM-Entry are repeated a plurality of times between the VMM 110 and the VMM 120.
  • the VM-Exit handler 10 reflects the change in the EPT 902 that performs GPA2-HPA conversion.
  • Steps S513 ⁇ S514 ⁇ S515 correspond to steps S1 ⁇ S2 ⁇ S10 ⁇ S30 in FIG. 10 ⁇ S31 ⁇ S32 ⁇ S33 ⁇ S61 in FIG.
  • step S5166 the VMM 120 executes a VM-Entry instruction to return the processing to the guest OS 140.
  • a VM-Entry instruction By executing the privileged instruction VM-Entry by the VMM 120 in the non-privileged mode, an exception occurs and the VMM 110 is VM-Exited.
  • step S517 the VM-Exit handler 10 identifies the VM-Exit factor as a VM-Entry instruction from the VMM 120 to the guest OS 140.
  • step S5108 the process moves to the guest OS 140.
  • the above steps S517 ⁇ S518 correspond to steps S1 ⁇ S2 ⁇ S10 ⁇ S21 ⁇ S22 in FIG.
  • FIG. 14 shows an example of the relationship of the DMAR table in the DMAR-HW nested virtualization.
  • the HPA address range of 4 GB to 10 GB is allocated as 0 GB to 6 GB of GPA1. Further, the address range 4 GB to 6 GB of GPA 1 is assigned as 0 GB to 2 GB of GPA 2.
  • the DMAR table 520 created on the GPA 2 includes a setting that the address range 1 GB to 2 GB of the GPA 2 is an area allocated to the I / O device 801.
  • the DMAR table 512 is obtained by converting the DMAR table 520 onto the GPA1, and the DMAR table 502 is obtained by converting the DMAR table 512 onto the HPA.
  • the DMAR table 502 includes a setting that the HPA address range 9 GB to 10 GB is an area allocated to the I / O device 801.
  • the DMAR table 501 is obtained by converting the DMAR table 510 created on the GPA 1 into the HPA by the VMM 120.
  • the role of the VMM 120 is to convert the GPA2-based DMAR table 520 created by the guest OS 140 into the GPA1-based DMAR table 512 and set it in the vDMAR-HW 211.
  • the settings made in the vDMAR-HW 211 are reflected on the DMAR-HW 200 by the VMM 110 in the first layer by converting the DMAR table 512 into the DMAR table 502 based on the HPA.
  • the VMM 120 is only a relay point until the DMAR table 520 created by the guest OS 140 is set in the DMAR-HW 200. If the VMM 110 can directly set the DMAR table 520 of the guest OS 140 in the DMAR-HW 200, it is not necessary to relay the VMM 120 in the second layer.
  • the VMM 120 in the second layer does not know that the guest OS 140 is using the vDAR-HW221.
  • the VMM 120 recognizes that the guest OS 140 is not using the vDAR-HW 221. That is, the VMM 120 in the second layer need only perform its own setting to the vDAR-HW 211 without being aware of the setting of the upper guest OS 140.
  • the DMAR settings made by the guest OS 140 and the VMM 120 in the second layer are finally reflected in the DMAR-HW 200 by the VMM 110 in the first layer. That is, as shown in the right diagram of FIG. 15, the GPA2-based DMAR table 520 is directly converted into the HPA-based DMAR table 502 by the VMM 110B (first-layer VMM of the disclosed technology).
  • FIG. 16 shows the information processing apparatus 100 according to the first embodiment.
  • the first-layer VMM 110B operating on the information processing apparatus 100 includes a VM-Exit handler 10B and a DMAR virtualization unit 11B.
  • the VM-Exit handler 10B is an example of a specific unit of the disclosed technology.
  • the DMAR virtualization unit 11B is an example of a setting unit of the disclosed technology.
  • the VM-Exit handler 10B captures the VM-Exit from the guest OS 140 or the VMM 120 and identifies the VM-Exit factor. The VM-Exit handler 10B determines, for the VM-Exit from the guest OS 140, whether the VM-Exit factor is “setting to the DMAR-HW 221” or “updating the DMAR table 520 set with WP”. When the VM-Exit factor is “setting to DMAR-HW 221” or “update of DMAR table 520 with WP setting”, the processing is not performed by the VMM 120 but executed by the VMM 110B.
  • the setting of the DMAR table in the DMAR-HW is performed by accessing the register of the DMAR-HW mapped in the memory.
  • the guest OS 140 accesses the memory and the VM-Exit is performed, if the accessed address matches the register address of the vDAR-HW 221 shown to the guest OS 140, the access is to the DMAR-HW 221.
  • the vDMAR-HW221 register address that the VMM 120 of the second layer shows to the guest OS 140 is the same as the address to which the register of the DMAR-HW200 is mapped. There must be. If the vMMAR-HW 221 register address that the second layer VMM 120 shows to the guest OS 140 is freely changed, the first layer VMM 110 has no way of knowing the address, and therefore detects access to the vDMAR-HW 221. I can't.
  • the VMM generally shows (virtualizes) the physical DMAR-HW register address as it is to the host guest, the above limitation is not particularly problematic.
  • the update of the DMAR table 520 set with the WP can be determined by checking whether or not the address matches the area in which the DMAR table 520 is stored when an exception occurs due to memory access.
  • a GPA2DMAR table acquisition unit 17 and a GPA2-HPA conversion unit 18 are added to the functional units of the DMAR virtualization unit 11 of the comparative example shown in FIG.
  • the GPA2 DMAR table acquisition unit 17 acquires the DMAR table 520 created by the guest OS 140 when the VM-Exit factor is the setting to the vDAR-HW 221 by the guest OS 140 or the update of the DMAR table 520.
  • GPA2-HPA conversion unit 18 converts GPA2 into HPA.
  • the GPA2-HPA conversion unit 18 is used when the DMAR table creation unit 15 creates the DMAR table 502 obtained by converting the DMAR table 520 created by the guest OS 140 into the HPA standard.
  • the GPA2-HPA converter 18 uses the EPT 902 that performs GPA2-HPA conversion created for the virtualization support mechanism of the CPU.
  • the memory 300 since the DMAR table 512 obtained by converting the DMAR table 520 into the GPA1 standard is not created, as shown in FIG. 18, the memory 300 has a DMAR unlike the memory configuration of the comparative example of FIG. An area for storing the table 512 is not provided.
  • the information processing apparatus 100 is realized by a server 40 having a nonvolatile storage unit 600 and an input / output interface (I / F) 800 in addition to a CPU 400, a memory 300, and a DMAR-HW 200. can do.
  • the CPU 400, the memory 300, the DMAR-HW 200, the storage unit 600, and the input / output I / F 800 are connected to each other via the bus 42.
  • the I / O devices 801 and 802 are connected to the server 40 via the input / output I / F 800.
  • the storage unit 600 can be realized by an HDD, a flash memory, or the like.
  • An information processing program 50 for causing the server 40 to function as the information processing apparatus 100 is stored in the storage unit 600 serving as a recording medium.
  • the CPU 400 reads the information processing program 50 from the storage unit 600 and develops it in the memory 300, and sequentially executes the processes included in the information processing program 50.
  • the information processing program 50 includes a VM-Exit handler process 51 and a DMAR virtualization process 52.
  • the CPU 400 operates as the VM-Exit handler 10B shown in FIG. 17 by executing the VM-Exit handler process 51.
  • the CPU 400 operates as the DMAR virtualization unit 11B illustrated in FIG. 17 by executing the DMAR virtualization process 52.
  • the server 40 that has executed the information processing program 50 functions as the information processing apparatus 100.
  • Each function realized by the CPU 400 can be realized by, for example, a semiconductor integrated circuit, more specifically, ASIC (Application ⁇ Specific Integrated Circuit) or the like.
  • ASIC Application ⁇ Specific Integrated Circuit
  • FIG. 20 shows a processing flow by the VM-Exit handler 10B.
  • FIG. 21 shows a flow of the DMAR virtualization process B by the DMAR virtualization unit 11B. It should be noted that the same processing as the DMAR-HW nested virtualization processing in the comparative example shown in FIGS. 10 to 12 is denoted by the same reference numeral, and detailed description thereof is omitted.
  • step S1 of the processing flow of the VM-Exit handler 10B shown in FIG. 20 the VM-Exit handler 10B captures the VM-Exit and specifies the VM-Exit factor.
  • step S2 the VM-Exit handler 10 determines whether the trapped VM-Exit is a VM-Exit from the guest OS 140 or a VM-Exit from the VMM 120. In the case of the VM-Exit of the guest OS 140, the process proceeds to step S51. In the case of the VM-Exit from the VMM 120, the process proceeds to step S10.
  • step S51 the VM-Exit handler 10B determines whether or not the VM-Exit factor determined in step S1 is the setting to the vDAR-HW 221 by the guest OS 140. In the case of setting to vDMAR-HW221, in order to continue the processing in the VMM 110, the process proceeds to step S20B, and in the case of not setting to vDMAR-HW221, the process proceeds to step S52.
  • step S52 the VM-Exit handler 10B determines whether or not the VM-Exit factor determined in step S1 is an update of the WP-set DMAR table 520 by the guest OS 140. In the case of updating the DMAR table 520 in which WP is set, the process proceeds to step S20B in order to continue the processing in the VMM 110. If it is not an update of the DMAR table 520 set with WP, the process proceeds to step S55.
  • step S20B the VM-Exit handler 10B executes a process (2B) for each VM-Exit factor.
  • the process (2B) for each VM-Exit factor is the same as the process (1) for each VM-Exit factor shown in FIG.
  • “setting to vDMAR-HW211” in step S31 is read as “setting to vDMAR-HW221”.
  • “update the WP-set DMAR table 510” in step S32 is read as “update the WP-set DMAR table 520”.
  • “DMAC virtualization processing” in step S100 is replaced with “DMAC virtualization processing B”.
  • “DAR virtualization process” in step S100 is replaced with “DAR virtualization process B”.
  • step S110 of the DMAR virtualization process B shown in FIG. 21 the VM-Exit handler 10B determines whether the VM-Exit factor is the setting to the vDAR-HW 221 by the guest OS 140 or the update of the WR-set DMAR table 520. judge. If the determination is affirmative, the process proceeds to step S121. On the other hand, if the VM-Exit factor is the setting to the vDMAR-HW 211 by the VMM 120 or the update of the DMAR table 510 with the WP setting, the process proceeds to step S131.
  • step S121 the GPA2 DMAR table acquisition unit 17 acquires the DMAR table 520 created by the guest OS 140 based on the address accessed by the guest OS 140.
  • the DMAR table 520 is created based on the GPA2 standard. Therefore, in the next step S122, the DMAR table creation unit 15 uses the GPA2-HPA conversion unit 18 to create the DMAR table 502 obtained by converting the GPA2-based DMAR table 520 into the HPA standard.
  • step S123 the host DMAR table update unit 16 updates the setting for the I / O device 801 in the DMAR table 500 with the contents of the DMAR table 502.
  • step S124 the WP setting unit 14 sets the WP setting of the memory area in which the DMAR table 520 is stored, so that the update of the DMAR table 520 by the guest OS 140 can be detected. To reflect.
  • the GPA1 DMAR table acquisition unit 12 acquires the DMAR table 510 created by the VMM 120 based on the address accessed by the VMM 120.
  • the DMAR table 510 is created based on the GPA1 standard. Therefore, in the next step S132, the DMAR table creation unit 15 creates the DMAR table 501 obtained by converting the GPA1-based DMAR table 510 into the HPA standard using the GPA1-HPA conversion unit 13.
  • step S133 the host DMAR table update unit 16 updates the setting for the I / O device 801 in the DMAR table 500 with the contents of the DMAR table 501.
  • step S134 the WP setting unit 14 sets the WP setting of the memory area in which the DMAR table 510 is stored to the EPT 901 that performs GPA1-HPA conversion of the CPU 400 so that the update of the DMAR table 510 by the VMM can be detected. reflect.
  • the process returns to the process (2B) for each VM-Exit factor shown in FIG.
  • FIG. 22 shows a transition between the non-privileged mode and the privileged mode in the DMAR-HW nested virtualization process in the first embodiment.
  • an I / O device 801 is assigned to the guest OS 140, and the guest OS 140 sets a DMAR table 520 that is a setting for the I / O device 801 in the vDAR-HW 221.
  • the VM-Exit from the non-privileged mode to the privileged mode is indicated by a one-dot chain line arrow
  • the VM-Entry from the privileged mode to the non-privileged mode is indicated by a two-dot chain line arrow.
  • the same parts as those in the transition between the non-privileged mode and the privileged mode in the DMAR-HW nested virtualization process are denoted by the same reference numerals, and detailed description thereof is omitted.
  • step S500 of FIG. 22 when the guest OS 140 accesses the register of the vDMAR-HW 221 to set the DMAR table 520 in the vDMAR-HW 221, it performs a VM-Exit to the VMM 110.
  • step S501 the VM-Exit handler 10B specifies a VM-Exit factor.
  • step S521 the VM-Exit handler 10B determines whether the VM-Exit factor is the setting to the vDAR-HW 221 by the guest OS 140 or the update of the DMAR table 520 in which the WP is set. If the VM-Exit factor is any one, the process proceeds to the next step S522 without moving the process to the VMM 120.
  • step S522 the GPA2 DMAR table acquisition unit 17 acquires the DMAR table 520. Then, the DMAR table creation unit 15 uses the GPA2-HPA conversion unit 18 to create the DMAR table 502 obtained by converting the GPA2-based DMAR table 520 into the HPA standard.
  • step S508 the host DMAR table update unit 16 updates the DMAR table 500 with the contents of the DMAR table 502.
  • step S523 the WP setting unit 14 reflects the WP setting of the memory area in which the DMAR table 520 is stored in the EPT 902.
  • step S518, the process moves to the guest OS 140.
  • Steps S501 ⁇ S521 ⁇ S522 ⁇ S508 ⁇ S523 ⁇ S518 are as follows: S1 ⁇ S2 ⁇ S51 ( ⁇ S52) ⁇ S20B ⁇ S31 ( ⁇ S32) ⁇ S100 ⁇ S121 ⁇ S122 ⁇ S123 of FIG. ⁇ S124 ⁇ corresponds to S22 in FIG.
  • FIG. 23 shows an example of the relationship of the DMAR table in the DMAR-HW nested virtualization in the first embodiment.
  • the relationship of the DMAR table and the allocation of the memory area in the virtualization of the DMAR-HW nested in the comparative example shown in FIG. 14 are the same.
  • the first embodiment is different in that the DMAR table 512 obtained by converting the DMAR table 520 into the GPA 1 is not created.
  • the second layer The processing is performed by the VMM in the first layer without moving the processing to the VMM. This makes it possible to reduce the transition between the non-privileged mode and the privileged mode, as is apparent from FIG. For this reason, it is possible to speed up the virtualization when providing the DMAR-HW to the guest OS in the nested virtualization environment.
  • the information processing apparatus 101 includes hardware resources such as a CPU 400, a memory 300, a DMAR-HW 200, and I / O devices 801, 802, 803, and 804.
  • the CPU 400 includes eight cores (cores 401, 402, ..., 408).
  • the DMAR-HW 200 controls DMA from the I / O devices 801, 802, 803, and 804.
  • the VMM 110B constructs the VMs 111 and 112, divides and allocates the hardware resources of the information processing apparatus 101 into the VM 111 and the VM 112, and monitors and controls the state.
  • Cores 401,..., 404 are assigned to the VM 111 and operate as the vCPUs 411,.
  • a part of the memory 300 is allocated to the VM 111 as the v memory 311.
  • I / O devices 801 and 802 are also directly assigned to the VM 111.
  • the VM 111 is provided with a vDMAR-HW 211.
  • the cores 405,..., 408 are allocated to the VM 112, and operate as the vCPUs 415,.
  • a part of the memory 300 is allocated to the VM 112 as the v memory 312.
  • I / O devices 803 and 804 are also directly assigned to the VM 112.
  • the VM 112 is also provided with a vDMAR-HW 212.
  • the vDMAR-HWs 211 and 212 are emulated by the VMM 110B, and the setting of the DMAR table in the vDMAR-HWs 211 and 212 is reflected in the DMAR-HW 200.
  • the VMM 120 in the second layer is operating on the VM 111, and the VMM 120 monitors and controls the state of the VM 121 operating on the VM 111.
  • the vCPU 411 is assigned to the VM 121 and operates as the vCPU 421 of the VM 121.
  • a part of the v memory 311 is allocated to the VM 121 as the v memory 321.
  • an I / O device 801 is also directly assigned to the VM 121.
  • the VM 121 is provided with vDMAR-HW221.
  • the vDMAR-HW 221 is emulated by the VMM 110B, and the setting of the DMAR table 520 in the vDMAR-HW 221 is reflected in the DMAR-HW 200.
  • the guest OS 140 is operating.
  • FIG. 25 shows the allocation of memory to the VMs 111, 112, and 121.
  • a range of 4 GB to 12 GB is allocated to the VM 111, and a range of 12 GB to 16 GB is allocated to the VM 112.
  • the memory space allocated to the VM 111 is GPA 11, and the memory space allocated to the VM 112 is GPA 12.
  • the range of 0 GB to 2 GB of HPA is used by the VMM 110 B, and the range of 2 GB to 4 GB is an area to which hardware registers and the like are mapped.
  • the 4 GB to 8 GB range in the memory space (GPA 11) of the VM 111 is allocated to the VM 121.
  • a memory space allocated to the VM 121 is referred to as GPA 21.
  • the VMM 110B creates an EPT necessary for the vCPU operating on the VM to access the memory and a DMAR table necessary for the I / O device assigned to the VM to access the memory on the memory.
  • the memory area in which the EPT and DMAR tables are stored ranges from 0 to 2 GB allocated for the VMM 110B.
  • FIG. 26 shows the EPT and DMAR table stored in the memory 300. Note that the above-described VMCS and the like are also stored in the memory 300, but the description thereof is omitted here.
  • the EPT 901 is an EPT that performs conversion from GPA 11 to HPA, and is set to the VMCS of the cores 401,.
  • the EPT 920 is an EPT that performs conversion from the GPA 12 to the HPA, and is set to the VMCS of the cores 405,.
  • FIG. 27 shows the DMAR table 500 set in the DMAR-HW 200.
  • the I / O device 801 has a bus number 10, a device number 1, and a function number 0.
  • the entry corresponding to the I / O device 801 refers to the root entry 10 of the bus number 10 in the route entry table 500A.
  • the context entry table 500B (Bus10) is referenced from the root entry 10.
  • the device number 1 and the function number 0 in the context entry table 500B (Bus10) correspond to the context entry 8.
  • Context entry 8 refers to the address conversion table 500C1.
  • the address conversion table 500C1 is a table for converting from GPA 11 to HPA.
  • the I / O device 802 is set to bus number 20, device number 2, and function number 0. Further, the I / O device 803 is assumed to have a bus number 30, a device number 3, and a function number 0. Further, the I / O device 804 is assumed to be a bus number 40, a device number 4, and a function number 0. Further, it is assumed that the address conversion table 500C2 is a table for converting from GPA 12 to HPA. In the example of FIG. 27, the I / O devices 801 and 802 assigned to the VM 111 refer to the address conversion table 500C1, and the I / O devices 803 and 804 assigned to the VM 112 refer to the address conversion table 500C2. I understand.
  • the VMM 120 creates the EPT 912 so that access to the v memory 321 by the vCPU 421 operating on the VM 121 is converted into access to the v memory 311.
  • the EPT 912 is a table that performs conversion from GPA 21 to GPA 11 and is created on the v memory 311.
  • the EPT 912 is set to the vVMCS of the vCPU 411.
  • the VMM 120 calls a VMWRITE instruction which is a privileged instruction.
  • the VMM 120 operating in the non-privileged mode calls the VMWRITE instruction, a VM-Exit is generated and the processing moves to the VMM 110B.
  • An EPT 902 is a table that performs conversion from GPA 21 to HPA.
  • the EPT 902 is created using an EPT 912 that performs conversion from GPA 21 to GPA 11 and an EPT 901 that performs conversion from GPA 11 to HPA.
  • the VMM 120 sets the DMAR table 510 in the vDMAR-HW 211.
  • the DMAR table 510 is for converting the DMA by the I / O device 801 assigned to the VM 121 from the GPA 21 to the GPA 11.
  • the VMM 120 accesses the register of the vDMAR-HW 211 in order to set the DMAR table 510, a VM-Exit occurs, and the process moves to the VMM 110B.
  • FIG. 28 shows the DMAR table 500 updated with the DMAR table 501.
  • the DMAR table 510 created by the VMM 120 converts the DMA of the I / O device 801 assigned to the VM 121 from GPA 21 to GPA 11.
  • the entry corresponding to the I / O device 802 in the DMAR table 510 is set to pass-through (facing the memory space of the VM 111). .
  • the DMA of the I / O device 801 is converted from GPA 21 to HPA.
  • the DMAR table 501 is created by using an address conversion table 500C4 in the DMAR table 510 that performs conversion from GPA 21 to GPA 11 and an EPT 901 that performs conversion from GPA 11 to HPA.
  • the settings of the I / O devices 801 and 802 assigned to the VM 111 are updated with the contents of the DMAR table 501.
  • the entry corresponding to the I / O device 801 in the DMAR table 500 is updated so as to refer to the address translation table 500C3.
  • the entry corresponding to the I / O device 802 in the DMAR table 500 is changed while referring to the address translation table 500C1 because the entry corresponding to the I / O device 802 in the DMAR table 501 has a pass-through setting. Not.
  • the VM 110B reflects the WP setting of the memory area in which the DMAR table 510 is created in the EPT 901 so that the VMM 120 can detect that the DMAR table 510 has been updated.
  • the VMM Entry is sent to the VMM 120 to return the processing.
  • the VMM 120 performs setting for moving the vCPU 421 in the vVMCS of the vCPU 411.
  • the setting to vVMCS involves execution of VMREAD / VMWRITE, which are privileged instructions, and is therefore VM-Exited and processed by VMM 110B.
  • VMREAD / VMWRITE which are privileged instructions
  • VMM 110B When these settings are completed, a VM-Entry instruction is executed in order to transfer processing to the guest OS 140.
  • the VMM 120 operating in the non-privileged mode calls the VM-Entry that is a privileged instruction
  • the VM-Exit is performed, and the process proceeds to the VMM 110B.
  • the VM 110B specifies that the VM-Exit factor is a call to the VM-Entry instruction
  • the VM 110B performs setting for operating the VM 121 in the VMCS of the core 401, and performs VM-Entry to the guest OS 140.
  • the guest OS 140 operating on the VM 121 sets the DMAR table 520 in the vDAR-HW 221 to limit the DMA of the I / O device 801.
  • a restriction is set to permit access to only the 0 to 2 GB area of the GPA 21 to the I / O device 801.
  • the address conversion table 500C6 of the DMAR table 520 is set to reject access to a range other than 0 to 2 GB of the GPA 21.
  • the guest OS 140 accesses a register of the vDAR-HW 221 in order to set the DMAR table 520 in the vDAR-HW 520. This access generates a VM-Exit.
  • the VMM 110B identifies that the VM-Exit factor is the setting of the DMAR table 520 in the vDMAR-HW 221, the VMM 110B proceeds with the process without moving the process to the VMM 120.
  • the VMM 110B creates a DMAR table 502 obtained by converting the DMAR table 520 in the GPA 21 space into the HPA space.
  • the address conversion table 500C6 of the DMAR table 520 is converted into the address conversion table 500C5 using the EPT 902 that performs conversion from the GPA 21 to the HPA.
  • the address conversion table 500C5 is configured to convert the area of 0 to 2 GB of the GPA 21 to the area of 6 GB to 8 GB of the HPA and deny access to other areas.
  • the VMM 110B changes the entry corresponding to the I / O device 801 in the DMAR table 500 to refer to the address conversion table 500C5 of the DMAR table 502.
  • the VM 110B reflects the WP setting of the memory area in which the DMAR table 520 is created in the EPT 902 so that the guest OS 140 can detect that the DMAR table 520 has been updated.
  • the VMM 110B executes a VM-Entry instruction to return the processing to the guest OS 140.
  • the DMAR-HW 200 is initialized by the guest OS 140 on the VM 121.
  • the address conversion table 500C8 in the DMAR table 520 is a setting indicating that only the address range 4 GB to 6 GB of the GPA 21 can be accessed.
  • the guest OS 140 creates the address conversion table 500C8 and updates the address conversion table 500C8 so that the entry corresponding to the I / O device 801 in the DMAR table 520 is referred to.
  • VM-Exit is generated by this update.
  • the process proceeds without being transferred to the VMM 120.
  • the VMM 110B specifies that the entry corresponding to the I / O device 801 in the DMAR table 520 refers to the new address translation table 500C8.
  • an address conversion table 500C7 obtained by converting the address conversion table 500C8 in the GPA 21 space into the HPA space is created, and the entry corresponding to the I / O device 801 in the DMAR table 502 is referred to.
  • the address conversion table 500C7 is also referred to from an entry corresponding to the I / O device 801 in the DMAR table 500. If the address conversion table 500C5 is no longer referred to by any entry, it may be deleted. Then, the WP setting of the memory area used by the address conversion table 500C6 is canceled, and the WP setting of the area of the address conversion table 500C8 is newly reflected in the EPT 902.
  • the DMAR table 500 set in the DMAR-HW 200 is updated by the guest OS 140 on the VM 121.
  • the setting of the DMAR table 500 in the DMAR-HW 200 when the VMM 120 deletes the VM 121 will be described.
  • the I / O device 801 assigned to the VM 121 is also released and placed in the management of the VMM 120.
  • the entry corresponding to the I / O device 801 in the DMAR table 510 managed by the VMM 120 refers to the address translation table 500C4. Therefore, in order to return this reference to the pass-through setting, the entry corresponding to the I / O device 801 in the DMAR table 510 is updated. Since the area of the DMAR table 510 is WP, a VM-Exit is generated by this update.
  • the VMM 110B makes the entry corresponding to the I / O device 801 in the DMAR table 500 refer again to the address conversion table 500C1 that performs GPA11-HPA conversion. If the address conversion table 500C3 is not referred to by any entry, it may be deleted. Then, it is reflected in the EPT 901 so as to release the WP of the memory area used by the address conversion table 500C4. Further, the DMAR table 502 is not referred to from the DMAR table 500 and may be deleted. Further, the WP setting of the memory area used by the DMAR table 520 is reflected to the EPT 902 so as to be released.
  • the DMAR table 500 is updated when the VM 121 is deleted.
  • the hardware resources of the information processing apparatus 102 according to the third embodiment are the same as those of the information processing apparatus 101 according to the second embodiment.
  • three layers of virtualization are configured.
  • the VMM 130 is present on the VM 121
  • the VM 131 is further constructed on the VMM 130
  • the guest OS 140 is operating on the VM 131.
  • a vCPU 431 and a v memory 331 are allocated to the VM 131, and an I / O device 801 is also directly allocated.
  • the VM 131 is provided with vDAR-HW231.
  • a memory space in which the guest OS 140 operates is GPA3.
  • FIG. 33 shows the DMAR table and EPT stored in the memory 300 in the configuration of FIG.
  • the memory 300 is different from the memory 300 configuration in the first embodiment shown in FIG. 17 in that a part of the area allocated to the v memory 321 is allocated to the v memory 331. Further, the GPA3-based DMAR table 530 created by the guest OS 140 is stored in the area allocated to the v memory 331. The memory 300 also stores a DMAR table 503 obtained by converting the DMAR table 530 into an HPA standard. Further, the memory 300 stores an EPT 903 which is a conversion table between GPA3 and HPA.
  • the VMM 110C includes a VM-Exit handler 10C and a DMAR virtualization unit 11C.
  • the DMAR virtualization unit 11C includes a GPA # nDMAR table acquisition unit 17C, a GPA # n-HPA conversion unit 18C, a WP setting unit 14, a DMAR table creation unit 15, and a host DMAR table update unit 16.
  • FIG. 35 shows a processing flow by the VM-Exit handler 10C.
  • FIG. 36 shows a VM-Exit processing flow from the VMM 120 in the processing flow by the VM-Exit handler 10C.
  • FIG. 37 shows the VM-Exit processing flow from the VMM 130 in the processing flow by the VM-Exit handler 10C.
  • FIG. 38 shows a flow of the DMAR virtualization process C by the DMAR virtualization unit 11C. Note that the same processing as the DMAR-HW nesting virtualization processing in the first embodiment shown in FIGS. 20 and 21 is denoted by the same reference numeral, and detailed description thereof is omitted.
  • step S1 of the processing flow of the VM-Exit handler 10C shown in FIG. 35 the VM-Exit handler 10C captures the VM-Exit from the guest OS 140, the VMM 120, or the VMM 130. Then, the VM-Exit handler 10C specifies the VM-Exit factor of the captured VM-Exit.
  • step S2 the VM-Exit handler 10C determines whether or not the captured VM-Exit is a VM-Exit from the guest OS 140. In the case of VM-Exit from the guest OS 140, the process proceeds to step S53, and in the case of VM-Exit from the VMM 120 or VMM 130, the process proceeds to step S3.
  • step S53 the VM-Exit handler 10C determines whether or not the VM-Exit factor determined in step S1 is the setting in the vDAR-HW 231 by the guest OS 140. In the case of setting to vDMAR-HW231, in order to continue the processing in the VMM 110C, the process proceeds to step S20C, and in the case of not setting to vDMAR-HW231, the process proceeds to step S54.
  • step S54 the VM-Exit handler 10C determines whether or not the VM-Exit factor determined in step S1 is an update of the WP-set DMAR table 530 by the guest OS 140. In the case of updating the DMAR table 530, the process proceeds to step S20C in order to continue the processing in the VMM 110C, and in the case of not updating the DMAR table 530, the process proceeds to step S55.
  • step S20C the VM-Exit handler 10C executes processing (2C) for each VM-Exit factor.
  • the process (2C) for each VM-Exit factor is the same as the process (1) for each VM-Exit factor shown in FIG.
  • “setting to vDMAR-HW211” in step S31 is read as “setting to vDMAR-HW231”.
  • “update of WP-set DMAR table 510” in step S32 is read as “update of WP-set DMAR table 530”.
  • “DMAC virtualization processing” in step S100 is replaced with “DMAC virtualization processing C”.
  • step S3 the VM-Exit handler 10C determines whether the trapped VM-Exit is a VM-Exit from the VMM 120 or not. In the case of the VM-Exit from the VMM 120, the process proceeds to step S80, and the VM-Exit process from the VMM 120 shown in FIG. 36 is executed. In the case of the VM-Exit from the VMM 130, the process proceeds to step S90, and the VM-Exit process from the VMM 130 shown in FIG. 37 is executed.
  • step S10 of the VM-Exit process from the VMM 120 the VM-Exit handler 10C determines whether or not the VM-Exit factor specified in step S1 is a VM-Entry instruction.
  • the VM-Exit handler 10 performs various settings for transferring processing to the VMM 130 in the VMCS.
  • step S42 the VM-Exit handler 10C performs VM-Entry to the VMM 130 in order to transfer the processing to the VMM 130, and returns to the processing of the VM-Exit handler 10C shown in FIG.
  • step S10 determines in step S10 that the VM-Exit factor is not a VM-Entry instruction
  • the process proceeds to step S30, and the processing (1) for each VM-Exit factor shown in FIG. Execute.
  • “DMA virtualization processing” in step S100 is replaced with “DMAC virtualization processing C”.
  • step S62 the VM-Exit handler 10C performs VM-Entry to the VMM 120 in order to transfer the processing to the VMM 120, and returns to the processing of the VM-Exit handler 10C shown in FIG.
  • step S10 of the VM-Exit process from the VMM 130 shown in FIG. 37 the VM-Exit handler 10C determines whether or not the VM-Exit factor specified in step S1 is a VM-Entry instruction. If the VM-Exit factor is a VM-Entry instruction, in step S21, the VM-Exit handler 10C performs various settings for transferring processing to the guest OS 140 to the VMCS. Next, in step S22, the VM-Exit handler 10C performs VM-Entry to the guest OS 140 in order to transfer the processing to the guest OS 140, and returns to the processing of the VM-Exit handler 10C shown in FIG.
  • step S10 determines in step S10 that the VM-Exit factor is not a VM-Entry instruction
  • the process proceeds to step S55.
  • step S55 the VM-Exit handler 10C determines whether the processing according to the VM-Exit factor is performed as it is by the VMM 110C or left to the VMM 120.
  • the process proceeds to step S40, and when processing is performed by the VMM 120, the process proceeds to step S61.
  • step S61 the VM-Exit handler 10C performs various settings in the VMCS for transferring processing to the VMM 120.
  • step S62 the VM-Exit handler 10C performs VM-Entry to the VMM 120 in order to transfer the processing to the VMM 120, and returns to the processing of the VM-Exit handler 10C shown in FIG.
  • step S40 the VM-Exit handler 10C executes the process (3) for each VM-Exit factor.
  • the process (3) for each VM-Exit factor is the same as the process (1) for each VM-Exit factor shown in FIG.
  • “setting to DMAR-HW 211” in step S31 is read as “setting to DMAR-HW 221”.
  • “update the WP-set DMAR table 510” in step S32 is read as “update the WP-set DMAR table 520”.
  • “DMAC virtualization processing” in step S100 is replaced with “DMAC virtualization processing C”.
  • step S42 the VM-Exit handler 10C performs VM-Entry to the VMM 130 in order to transfer the processing to the VMM 130, and returns to the processing of the VM-Exit handler 10C shown in FIG.
  • the VM-Exit handler 10C determines whether the VM-Exit factor is set to the vDAR-HW 231 by the guest OS 140 or the WR-set DMAR table 530 is updated. Determine whether or not. If the determination is affirmative, the process proceeds to step S141. If the determination is negative, the process proceeds to step S120.
  • step S141 the GPA # nDMAR table acquisition unit 17C acquires the DMAR table 530 created by the guest OS 140.
  • the DMAR table 530 is created based on the GPA3 standard. Therefore, in the next step S142, the DMAR table creation unit 15 creates a DMAR table 503 obtained by converting the GPA3-based DMAR table 520 into the HPA standard using the GPA # n-HPA conversion unit 18C.
  • step S143 the host DMAR table update unit 16 updates the setting for the I / O device 801 in the DMAR table 500 with the contents of the DMAR table 503.
  • step S144 the WP setting unit 14 sets the WP setting of the memory area in which the DMAR table 530 is stored, and performs the GPA3-HPA conversion of the CPU 400 so that the update of the DMAR table 530 by the guest OS 140 can be detected. To reflect.
  • the VM-Exit handler 10C determines whether the VM-Exit factor is the setting to the vDAR-HW 221 by the VMM 130 or the update of the DMAR table 520 in which the WR is set. If the determination is affirmative, the process proceeds to step S121, and if the VM-Exit factor is the setting to the vDAR-HW 211 by the VMM 120 or the update of the DMAR table 510 in which the WR is set, the determination is negative, and the process proceeds to step S131. .
  • steps S121 to S124 and 131 to 134 are executed, and the process returns to the process of the VM-Exit handler 10C shown in FIG.
  • FIG. 39 shows a transition between the non-privileged mode and the privileged mode in the DMAR-HW nested virtualization process in the third embodiment.
  • an I / O device 801 is assigned to the guest OS 140, and the guest OS 140 performs settings for the I / O device 801 in the vDAR-HW 231.
  • the VM-Exit from the non-privileged mode to the privileged mode is indicated by a one-dot chain line arrow
  • the VM-Entry from the privileged mode to the non-privileged mode is indicated by a two-dot chain line arrow.
  • the transition between the non-privileged mode and the privileged mode in the third embodiment is the same as the transition between the non-privileged mode and the privileged mode in the first embodiment shown in FIG.
  • the disclosed technology can be similarly applied.
  • the setting or update of the GPA # n-based DMAR table by the upper guest OS is detected. If these are detected, the DMAR table created based on the GPA # n standard may be converted into the HPA standard DMAR table by the VMM of the first layer without moving the processing to the higher-order VMM.
  • VT-x and VT-d of Intel have been described as examples of the virtualization support mechanism of the CPU and the virtualization support mechanism of the DMAR-HW.
  • the present invention is not limited to this. Any CPU virtualization support mechanism may be used as long as the CPU operates in a privileged mode and a non-privileged mode.
  • the DMAR-HW virtualization support mechanism may be a mechanism that performs DMA using a conversion table.
  • the mode in which the information processing program 50 as an example of the information processing program in the disclosed technology is stored (installed) in the storage unit 600 in advance has been described.
  • the information processing program in the disclosed technology can be provided in a form recorded on a recording medium such as a CD-ROM or a DVD-ROM.

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)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

　入れ子の仮想化環境におけるゲストプログラムに、ＤＭＡＲ－ＨＷを提供する際の仮想化を高速化する。第１層ＶＭＭ、第１層ＶＭ、第２層ＶＭＭ、第２層ＶＭを含む入れ子の仮想化環境で、ＶＭ－Ｅｘｉｔハンドラが、第１層ＶＭ上で動作するゲストＯＳからのＶＭ－Ｅｘｉｔを捕捉する。ＶＭ－Ｅｘｉｔハンドラは、ＶＭ－Ｅｘｉｔ要因を特定する。ＶＭ－Ｅｘｉｔ要因が、ゲストＯＳによるｖＤＭＡＲ－ＨＷへのＤＭＡＲテーブルの設定または更新の場合には、第２層ＶＭＭへ処理を移すことなく、第１層ＶＭＭでＶＭ－Ｅｘｉｔ要因に応じた処理を実行する。ＤＭＡＲ仮想化部は、ゲストＯＳが作成したＤＭＡＲテーブルを取得し、ゲストＯＳのゲストメモリ空間をホストメモリ空間に変換したＤＭＡＲテーブルを作成し、ＤＭＡＲ－ＨＷに設定する。

Description

情報処理装置、方法、及びプログラム
　開示の技術は、情報処理装置、情報処理方法、及び情報処理プログラムに関する。
　近年、コンピュータ上に仮想的なコンピュータ（仮想マシン）を構築する仮想化技術において、入れ子の仮想化技術が提案されている。入れ子の仮想化技術とは、仮想マシン上で仮想マシンを動かす仮想化技術であり、例えば、ＢＩＯＳ（Basic Input Output System）が仮想マシンを立ち上げる。そして、その仮想マシン上でＸｅｎ（登録商標）などの既存の仮想化ソフト（仮想マシンモニタ）を動かすような技術である。
　また、仮想マシンを構築する仮想マシンモニタは、基本的にはソフトウェアによる処理を行っているが、仮想マシンモニタの処理の一部をハードウェアにより担う仮想化支援機構を利用した仮想マシンモニタも存在する。
　さらに、上記の入れ子の仮想化技術における第２層の仮想化に対して、ハードウェアによる仮想化支援機構を仮想化して提供する技術が提案されている。例えば、仮想化支援機構を備えたＣＰＵが、通常モードと仮想化支援機構を提供するモードとで動作する仮想化技術が提案されている。この技術では、仮想化支援機構を提供するモードでは、ホストＶＭＭ（Virtual Machine Monitor）が、ゲストＯＳ（Operating System）を監視する。そして、ＣＰＵの動作モードを、ホストＶＭＭが動作するホストモードと、ゲストＶＭＭまたはユーザプログラムが動作するユーザモードとに切り替える。そして、所定の条件でホストＶＭＭがゲストＶＭＭ及びゲストＯＳの命令をエミュレートする。これにより、ゲストＯＳが稼働する仮想マシンに割り当てられた仮想ＣＰＵが、ゲストＯＳに対して、仮想化支援機構を提供するように見せかける。
　また、仮想マシンに割り当てられたＩ／Ｏ（Input/Output）デバイス（入出力装置）がメモリ空間へアクセスすることをＤＭＡ（Direct Memory Access）という。このＩ／ＯデバイスによるＤＭＡのアドレス変換を行う仮想化支援機構として、ＤＭＡＲ（ＤＭＡ Remapping）という技術が提案されている。このＤＭＡＲの仮想化支援機構を提供するハードウェアをＤＭＡＲ－ＨＷ（hardware）という。
特開２００９－３７４９号公報
「Intel Virtualization Technology for Directed I/O Architecture Specification」、［online］、Intel corp．発行、［平成２５年３月１９日検索］、インターネット＜ＵＲＬ：http://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices＞
　従来技術のＤＭＡＲ－ＨＷのような入出力装置のＤＭＡのアドレス変換を行うハードウェアによる変換機構は、１階層の仮想化のみに対応している。従って、入れ子の仮想化技術における第２層より上位の仮想マシンモニタやゲストプログラムでは使用できない、という問題がある。
　上述の入れ子の仮想化における第２層の仮想化に仮想化支援機構を提供する従来技術を、ＤＭＡＲ－ＨＷの仮想化に対して適用することも考えられる。しかし、処理が煩雑であるため、オーバヘッドが大きくなり、ゲストプログラムに提供するためのＤＭＡＲ－ＨＷの仮想化に時間を要する、という問題がある。
　開示の技術は、一つの側面として、入れ子の仮想化環境におけるゲストプログラムに、入出力装置によるＤＭＡのアドレス変換を行うハードウェアによる変換機構を提供する際の仮想化を高速化することが目的である。
　開示の技術は、入れ子の仮想化環境において、ゲストプログラムの処理で発生した非特権モードから特権モードへの遷移の要因を特定する特定部を備えている。入れ子の仮想化環境とは、第１層の仮想マシンモニタにより構築された仮想マシン上で動作する上位仮想マシンモニタにより上位仮想マシンが構築された仮想化環境である。また、前記第１層の仮想マシンモニタが特権モードで動作し、前記上位仮想マシンモニタ及び前記上位仮想マシン上のゲストプログラムが非特権モードで動作する。また、開示の技術は、前記特定部により特定された要因が、仮想変換テーブルの設定または更新の場合に、変換機構で用いる変換テーブルを設定する設定部を備えている。仮想変換テーブルは、前記上位仮想マシンに割り当てられた入出力装置によるＤＭＡのアドレス変換を設定された変換テーブルを用いて行うハードウェアの変換機構を仮想化して前記ゲストプログラムに提供される仮想変換機構で用いる。設定部は、前記仮想変換テーブル、及び前記ゲストプログラムが動作するゲストメモリ空間と前記第１層の仮想マシンモニタが動作するホストメモリ空間との対応関係に基づいて、前記変換機構で用いる前記変換テーブルを設定する。
　開示の技術は、一つの側面として、入れ子の仮想化環境におけるゲストプログラムに、入出力装置によるＤＭＡのアドレス変換を行うハードウェアによる変換機構を提供する際の仮想化を高速化することができる、という効果を有する。
ＤＭＡＲ－ＨＷによるアドレス変換を示す概略図である。 ＤＭＡＲテーブルの一例を示す図である。 ＤＭＡＲ－ＨＷの仮想化の概略を示す構成図である。 ＨＰＡとＧＰＡとにおけるＤＭＡＲテーブルの関係を示す図である。 ＤＭＡＲテーブルの更新を説明するための図である。 入れ子の仮想化構成でのＣＰＵの仮想化支援機構の概略を示す構成図である。 比較例の概略を示す構成図である。 比較例のメモリ構成を示す概略図である。 比較例におけるＶＭＭの機能ブロック図である。 比較例におけるＶＭ－Ｅｘｉｔハンドラの処理を示すフローチャートである。 比較例におけるＶＭ－Ｅｘｉｔ要因毎の処理を示すフローチャートである。 比較例におけるＤＭＡＲ仮想化処理を示すフローチャートである。 比較例における非特権モードと特権モードとの遷移を説明するための図である。 比較例におけるＨＰＡとＧＰＡ１とＧＰＡ２とにおけるＤＭＡＲテーブルの関係を示す図である。 開示の技術の概要を示す図である。 第１実施形態の構成を示す概略図である。 第１実施形態におけるＶＭＭの機能ブロック図である。 第１実施形態のメモリ構成を示す概略図である。 情報処理装置として機能するサーバの一例を示す概略ブロック図である。 第１実施形態におけるＶＭ－Ｅｘｉｔハンドラの処理を示すフローチャートである。 第１実施形態におけるＤＭＡＲ仮想化処理を示すフローチャートである。 第１実施形態における非特権モードと特権モードとの遷移を説明するための図である。 第１実施形態におけるＨＰＡとＧＰＡ１とＧＰＡ２とにおけるＤＭＡＲテーブルの関係を示す図である。 第２実施形態の構成を示す概略図である。 第２実施形態におけるメモリの割り当てを示す図である。 第２実施形態のメモリ構成を示す概略図である。 第２実施形態におけるＤＭＡＲテーブルを示す図である。 第２実施形態におけるＤＭＡＲテーブルの設定を示す図である。 第２実施形態におけるＤＭＡＲテーブルの設定を示す図である。 第２実施形態におけるＤＭＡＲテーブルの更新を示す図である。 第２実施形態におけるＤＭＡＲテーブルの設定の削除を示す図である。 第３実施形態の構成を示す概略図である。 第３実施形態のメモリ構成を示す概略図である。 第３実施形態におけるＶＭＭの機能ブロック図である。 第３実施形態におけるＶＭ－Ｅｘｉｔハンドラの処理を示すフローチャートである。 第３実施形態におけるＶＭＭ１２０からのＶＭ－Ｅｘｉｔ処理を示すフローチャートである。 第３実施形態におけるＶＭＭ１３０からのＶＭ－Ｅｘｉｔ処理を示すフローチャートである。 第３実施形態におけるＤＭＡＲ仮想化処理を示すフローチャートである。 第３実施形態における非特権モードと特権モードとの遷移を説明するための図である。
　まず、第１実施形態の詳細を説明する前に、従来の入れ子の仮想化技術と、従来のＤＭＡＲ－ＨＷ（Direct Memory Access Remapping - hardware）の仮想化技術とをそのまま組み合わせた場合の問題点を、以下の各項目に従って説明する。
＜ＤＭＡＲ－ＨＷの概要＞
　仮想マシンモニタ（ＶＭＭ：Virtual Machine Monitor）により構築された仮想マシン（ＶＭ：Virtual Machine）上のゲストＯＳ（Operating System）は、使用するＩ／Ｏ（Input/Output）デバイスにゲストメモリ空間上のメモリリソースを割り当てる。Ｉ／Ｏデバイスがこの割り当てられたメモリリソースへアクセスする際には、ゲストメモリ空間上のアドレス（ＧＰＡ：Guest Physical Address）からホストメモリ空間上のアドレス（ＨＰＡ：Host Physical Address）へ変換する必要がある。この変換を行うのがＤＭＡＲであり、ＤＭＡＲを行うハードウェアをＤＭＡＲ－ＨＷという。
　例えば、図１に示すように、Ｉ／Ｏデバイス８０１、８０２にゲストメモリ空間の０～２ＧＢの領域が割り当てられており、このゲストメモリ空間の０～２ＧＢの領域が、ホストメモリ空間の４ＧＢ～６ＧＢの領域に対応するとする。Ｉ／Ｏデバイス８０１または８０２が、ゲストメモリ空間の０～２ＧＢの領域内のアドレスにアクセスする。すると、Ｉ／Ｏデバイスがアクセスしたゲストメモリ空間のアドレス（ＧＰＡ）が、ＤＭＡＲ－ＨＷ２００により、ホストメモリ空間のアドレス（ＨＰＡ）に変換される。
　Ｉ／Ｏデバイスがアクセスしたアドレスを、ＧＰＡからＨＰＡへ変換するためには、どのような変換を行うかを示した変換表（ＤＭＡＲテーブル）を、ＤＭＡＲ－ＨＷ２００に設定しておく必要がある。この変換表は、メモリ上に作成されて、その先頭のアドレスがＤＭＡＲ－ＨＷ２００のレジスタに設定される。
　例えば、インテル（登録商標）のＤＭＡＲ－ＨＷによる仮想化支援機構であるＶＴ－ｄにおけるＤＭＡＲテーブル５００の構成例を、図２に示す。図２の例では、ＤＭＡＲ－ＨＷ２００のレジスタは、メモリ上の特定の領域にマップされている。ＤＭＡＲテーブル５００へのＩ／Ｏデバイスに対応したエントリは、バス番号（Ｂｕｓ）、デバイス番号（Ｄｅｖ）、及びファンクション番号（Ｆｕｎ）を含む。ＤＭＡＲテーブル５００は階層構造になっており、第１階層のルートエントリテーブル５００ＡでＩ／Ｏデバイスのバス番号を分類し、第２階層のコンテキストエントリテーブル５００ＢでＩ／Ｏデバイスのデバイス番号及びファンクション番号を分類する。第３階層以降はアドレス変換テーブル５００Ｃと呼ばれ、Ｉ／ＯデバイスがアクセスするＧＰＡをＨＰＡに変換するための変換方法が設定されている。複数のＩ／Ｏデバイスで同じ変換方法を適用する場合には、アドレス変換テーブルを共有して使用することが可能である。
　すなわち、ＤＭＡＲテーブル５００は、Ｉ／Ｏデバイスに対応したエントリと、ＧＰＡ－ＨＰＡの変換方法との対応付けを定めるものである。
　ＤＭＡＲ－ＨＷが、このような変換表を用いてＧＰＡをＨＰＡに変換することにより、ＶＭ上で動作するゲストＯＳに、直接Ｉ／Ｏデバイスを割り当てることができる。
　なお、ＤＭＡＲ－ＨＷは、ＶＭＭ以外の通常のＯＳにも使用することができる。例えば、特定のメモリ領域を保護したい場合に、Ｉ／Ｏデバイスからその領域へのＤＭＡができないようにＤＭＡＲテーブルを設定すればよい。
＜ＤＭＡＲ－ＨＷの仮想化＞
　ＶＭ上で動作するゲストＯＳがＤＭＡＲ－ＨＷを使用できるように、ＶＭＭはＤＭＡＲ－ＨＷを仮想化してゲストＯＳに提供する必要がある。この仮想化には、例えば、インテル（登録商標）ＶＴ－ｘのようなＣＰＵの仮想化支援機構を利用することができる。
　図３に、情報処理装置１５１で実現されるＤＭＡＲ－ＨＷの仮想化の一例を示す。情報処理装置１５１は、ハードウェアリソースであるＣＰＵ４００、メモリ３００、ＤＭＡＲ－ＨＷ２００、及びＩ／Ｏデバイス８０１、８０２を備えている。ＣＰＵ４００は、例えばインテル（登録商標）ＶＴ－ｘのようなハードウェアによる仮想化支援機構４９０を備えている。情報処理装置１５１において、ＶＭＭ１１０を動作させ、ＶＭ１１１、１１２を構築し、ＶＭ１１１上でゲストＯＳ１４０を動作させている。
　ＶＭＭ１１０は、ＶＭ－Ｅｘｉｔハンドラ１０と、ＤＭＡＲ仮想化部１１とを備えている。ＤＭＡＲ仮想化部１１は、ＤＭＡＲ－ＨＷ２００を仮想化してＶＭ１１１に提供し、ｖ（virtual）ＤＭＡＲ－ＨＷ２１１としてゲストＯＳ１４０に見せる。同様に、ＶＭ１１２には、ｖＤＭＡＲ－ＨＷ２１２が提供される。また、ＤＭＡＲ仮想化部１１は、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２１１のレジスタへのアクセスを監視する。ＤＭＡＲ－ＨＷ２００のレジスタは、メモリ空間の特定のアドレスにマップされているので、ＤＭＡＲ仮想化部１１は、ｖＤＭＡＲ－ＨＷ２１１のレジスタも同じ位置にマップされているようにゲストＯＳ１４０に見せる。ゲストＯＳ１４０がそのマップされたレジスタにアクセスした場合に、例外が発生するようにＣＰＵ４００の仮想化支援機構４９０へ設定する。ＶＭ　Ｅｘｉｔハンドラ１０は、例外が発生した場合に、その要因を特定し、それがゲストＯＳ１４０によるそのマップされたレジスタへのアクセスである場合に、ＤＭＡＲ仮想化部１１を呼び出す。
　ＤＭＡＲ仮想化部１１は、ゲストＯＳ１４０がｖＤＭＡＲ－ＨＷ２１１のレジスタに設定しようとしたアドレスから、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５１０の場所を特定する。ＤＭＡＲテーブル５１０は、ＶＭＭ１１０により割り当てられたＩ／ＯデバイスをゲストＯＳ１４０が初期化する際に、ｖＤＭＡＲ－ＨＷ２１１へ設定されるＤＭＡＲテーブルである。ＤＭＡＲテーブル５１０は、ゲストＯＳ１４０により、ＧＰＡ上に作成されており、Ｉ／Ｏデバイスに割り当てられたＧＰＡ空間上の領域に関する設定が含まれる。ＶＭＭ１１０は、ＶＭＭ１１０が管理するＧＰＡ空間からＨＰＡ空間へのアドレス変換方法に基づいて、ＤＭＡＲテーブル５１０の内容をＨＰＡ空間上へ変換したＤＭＡＲテーブル５０１を作成する。
　ＤＭＡＲ－ＨＷ２００には、予めＤＭＡＲテーブル５００が設定される。例えば、ＶＭ１１１へＩ／Ｏデバイス８０１が割り振られ、ＶＭ１１２へＩ／Ｏデバイス８０２が割り振られているとする。この場合、ＤＭＡＲテーブル５００には、ＶＭ１１１へ割り振られたＩ／Ｏデバイス８０１のＤＭＡを変換する設定と、ＶＭ１１２へ割り振られたＩ／Ｏデバイス８０２のＤＭＡを変換する設定とが含まれる。
　ＤＭＡＲ仮想化部１１は、ＤＭＡＲテーブル５００の内、ゲストＯＳ１４０が動作するＶＭ１１１に割り振られたＩ／Ｏデバイス８０１に関する設定を、ＤＭＡＲテーブル５０１の内容で更新する。なお、ＤＭＡＲテーブルの更新方法については、後述する。
　また、ＤＭＡＲ仮想化部１１は、ＣＰＵ４００の仮想化支援機構４９０を使用して、ＤＭＡＲテーブル５１０の置かれた領域をＷＰ（Write Protect）に設定する。これはゲストＯＳ１４０によるＤＭＡＲテーブル５１０の更新を検出するためである。ＤＭＡＲテーブル５１０の更新を検出した場合には、その更新内容をＤＭＡＲテーブル５０１へ反映するようにエミュレーションすることも可能である。
　図４に、図３に示すＤＭＡＲ－ＨＷの仮想化でのＨＰＡとＧＰＡとにおけるＤＭＡＲテーブルの関係を示す。図４の例では、ＨＰＡのアドレス範囲４ＧＢ～６ＧＢが、ＧＰＡの０ＧＢ～２ＧＢとして割り当てられている。ゲストＯＳ１４０により、ＧＰＡ上に作成されたＤＭＡＲテーブル５１０には、ＧＰＡのアドレス範囲１ＧＢ～２ＧＢがＩ／Ｏデバイス８０１に割り当てられた領域であるとの設定が含まれる。ＤＭＡＲテーブル５１０をＨＰＡ上に変換したものがＤＭＡＲテーブル５０１であり、ＤＭＡＲテーブル５０１には、ＨＰＡのアドレス範囲５ＧＢ～６ＧＢがＩ／Ｏデバイス８０１に割り当てられた領域であるとの設定が含まれる。このように変換されたＤＭＡＲテーブル５０１に基づいて、予め設定されていた（初期状態の）ＤＭＡＲテーブル５００を更新する。
＜ＤＭＡＲテーブルの更新＞
　図５に、ＤＭＡＲテーブル５００の更新の一例を示す。例えばＩ／Ｏデバイス８０１に対応するエントリが、バス番号（Ｂｕｓ）Ｎ、デバイス番号（Ｄｅｖ）ｉ、及びファンクション番号（Ｆｕｎ）ｊであるとする。バス番号Ｎは、ルートエントリテーブル５００ＡのRoot entry Ｎに該当し、デバイス番号ｉ及びファンクション番号ｊは、Root entry Ｎに対応するコンテキストエントリテーブル５００ＢのContext entry Ｍに該当するものとする。初期状態のＤＭＡＲテーブル５００では、このエントリがアドレス変換テーブル５００Ｃ１を参照していたとする。この場合、ＤＭＡＲテーブル５０１の一部で、ゲストＯＳ１４０がＩ／Ｏデバイス８０１に与えた設定をＨＰＡ上へ変換したものがアドレス変換テーブル５００Ｃ２であるとする。ＤＭＡＲテーブル５００の更新は、Root entry Ｎ及びContext entry Ｍのエントリ、すなわちＩ／Ｏデバイス８００のエントリの参照を、アドレス変換テーブル５００Ｃ１からアドレス変換テーブル５００Ｃ２へ変更することで行われる。
＜入れ子の仮想化構成でのＣＰＵの仮想化支援機構の動作＞
　例えばインテル（登録商標）のＣＰＵの仮想化支援機構であるＶＴ－ｘでは、ＣＰＵに特権モードと非特権モードという２つの動作モードを与えている。ＣＰＵが非特権モードにあるときには、使用可能な機能が限られており、特権命令の実行などの許されていない処理を行うと、例外が発生し、特権モードへ遷移する。一方、ＣＰＵが特権モードにあるときは、全ての特権命令を実行することが可能であり、非特権モードで起きた例外を監視及び捕捉する役割を持つ。ＣＰＵの動作モードが、特権モードから非特権モードへ遷移することをＶＭ－Ｅｎｔｒｙといい、非特権モードから特権モードへ遷移することをＶＭ－Ｅｘｉｔという。
　図６に、情報処理装置１５２で実現される入れ子の仮想化の一例を示す。なお、図３に示す従来技術のＤＭＡＲ－ＨＷの仮想化の例と同一の部分については、同一符号を付して、詳細な説明を省略する。
　情報処理装置１５２は、ハードウェアリソースであるＣＰＵ４００及びメモリ３００を備えている。情報処理装置１５２において、第１層のＶＭＭ１１０を動作させ、第１層のＶＭ１１１を構築している。さらに、ＶＭ１１１上で第２層のＶＭＭ１２０を動作させ、第２層のＶＭ１２１を構築し、ＶＭ１２１上でゲストＯＳ１４０を動作させている。ＶＭＭ１１０は特権モードで動作し、ＶＭＭ１２０及びゲストＯＳ１４０は非特権モードで動作する。なお、ＶＭＭ１１０が動作するホストメモリ空間をＨＰＡ、ＶＭＭ１２０が動作するゲストメモリ空間をＧＰＡ１、及びゲストＯＳ１４０が動作するゲストメモリ空間をＧＰＡ２とする。
　また、ＶＭ１１１には、ｖ（virtual）メモリ３１０及びｖ（virtual）ＣＰＵ４１０が割り当てられている。また、ＶＭ１２１には、ｖ（virtual）メモリ３２０及びｖ（virtual）ＣＰＵ４２０が割り当てられている。
　図３の場合と同様、ＣＰＵ４００は、例えばインテル（登録商標）ＶＴ－ｘのようなハードウェアによる仮想化支援機構４９０を備えている。ＶＴ－ｘでは、ＶＭＣＳ（Virtual Machine Control Structure）というＣＰＵの状態を保持する領域をメモリ上に作成し、ＶＭＣＳのアドレスを仮想化支援機構４９０に参照させて、ＣＰＵ４００の状態（特権モード、非特権モード等）を管理する。
　ＶＭＣＳ７００は、特権モードで動作するホストの状態を保持するホスト状態保持部７０１、非特権モードで動作するゲストの状態を保持するゲスト状態保持部７０２、及びその他の設定や状態などの制御情報を保持する制御情報保持部７０３を備えている。
　特権モードから非特権モードへの遷移であるＶＭ－Ｅｎｔｒｙが発生すると、ホスト上のＣＰＵ４００の状態がホスト状態保持部７０１へ保持され、ゲスト状態保持部７０２に保持されていた内容がＣＰＵ４００にロードされる。一方、非特権モードから特権モードへの遷移であるＶＭ－Ｅｘｉｔが発生すると、ゲストのＣＰＵ（ｖＣＰＵ４１０）の状態がゲスト状態保持部７０２に保持されて、ホスト状態保持部７０１に保持されていた内容がＣＰＵ４００にロードされる。また、制御情報保持部７０３へは、例えばどういった要因でＶＭ－Ｅｘｉｔさせるかといった設定や、実際にＶＭ－Ｅｘｉｔした場合の要因の特定、後述するＣＰＵのＧＰＡ－ＨＰＡ変換を行うＥＰＴ（Extended Page Table）の設定などを行う。
　入れ子の仮想化では、ＶＭ１１１に割り当てられたｖＣＰＵ４１０の状態を保持するためのｖ（virtual）ＶＭＣＳ７１０が存在する。ｖＶＭＣＳ７１０は、ＶＭ１１１に割り当てられたｖメモリ３１０に設けられ、ＶＭＣＳ７００と同様に、ホスト状態保持部７１１、ゲスト状態保持部７１２、及び制御情報保持部７１３を備えている。ｖＶＭＣＳ７１０のホスト状態保持部７１１には、ＶＭＭ１２０を動作させているｖＣＰＵ４１０の状態が、ゲスト状態保持部７１２には、ゲストＯＳ１４０を動作させているｖＣＰＵ４２０の状態が格納される。
　また、メモリ３００には、ＶＭＣＳ７００の退避領域であるＶＭＣＳ－Ｃ（Copy）６００も置かれる。ＶＭＣＳ－Ｃ６００も、ＶＭＣＳ７００と同様に、ホスト状態保持部６０１、ゲスト状態保持部６０２、及び制御情報保持部６０３を備えている。ＶＭＣＳ－Ｃ６００の使い方については、後述する。
　ＶＭＣＳに対して読み書きを実行する場合には、特権命令であるＶＭＲＥＡＤ命令やＶＭＷＲＩＴＥ命令を使用する。例えば、第２層のＶＭＭ１２０がｖＶＭＣＳ７１０のゲスト状態保持部７１２へゲストＯＳ１４０を動作させるための設定を行いたい場合は、ＶＭＷＲＩＴＥ命令を実行する。しかし特権命令であるＶＭＷＲＩＴＥ命令を、非特権モードで動作しているＶＭＭ１２０が実行しようとすると、例外が発生し、ＶＭ－ＥｘｉｔしてＶＭＭ１１０へ処理が移る。ＶＭＭ１１０は、ＶＭ－Ｅｘｉｔした要因（以下、「ＶＭ－Ｅｘｉｔ要因」という）がＶＭＷＲＩＴＥ命令の実行であることを特定する。そして、ＶＭＷＲＩＴＥ命令で書かれようとした内容をｖＶＭＣＳ７１０のゲスト状態保持部７１２へ反映し、ＶＭ－Ｅｎｔｒｙして、ＶＭＭ１２０へ処理を戻す。
　ＶＭＭ１２０へ処理が戻ると、ＶＭＭ１２０では、ゲストＯＳ１４０へ処理を移すために、ＶＭ－Ｅｎｔｒｙ命令を実行する。しかし非特権モードで動作しているＶＭＭ１２０が、特権命令であるＶＭ－Ｅｎｔｒｙ命令を実行しようとすると、例外が発生し、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。
　ＶＭＭ１１０は、ＶＭ－Ｅｘｉｔ要因がＶＭ－Ｅｎｔｒｙ命令の実行であることを特定すると、ＶＭＣＳ７００のゲスト状態保持部７０２に保持されているｖＣＰＵ４１０の状態をｖＶＭＣＳ７１０のホスト状態保持部７１１へコピーする。そして、ｖＶＭＣＳ７１０のゲスト状態保持部７１２に保持されているｖＣＰＵ４２０の状態をＶＭＣＳ７００のゲスト状態保持部７０２へ設定する。
　次に、ＶＭＣＳ７００の制御情報保持部７０３に保持されているＶＭＭ１２０を監視及び制御していた設定を、ＶＭＣＳ－Ｃ６００の制御情報保持部６０３へ退避する。そして、ゲストＯＳ１４０を監視及び制御するための設定を、ＶＭＣＳ７００の制御情報保持部７０３へ行う。この設定は、ＶＭＣＳ－Ｃ６００の制御情報保持部６０３に保持されたＶＭＭ１１０がＶＭＭ１２０を監視及び制御するための設定と、ｖＶＭＣＳ７１０の制御情報保持部７１３に保持されたＶＭＭ１２０がゲストＯＳ１４０を監視及び制御するための設定とから作成される。
　ＶＭＭ１１０がゲストＯＳ１４０を監視及び制御するための設定を、ＶＭＭ１１０がＶＭＭ１２０を監視及び制御するための設定とＶＭＭ１２０がゲストＯＳ１４０を監視及び制御するための設定とを組み合わせて作成する理由を説明する。例えば、ＶＭＭ１１０が特定のハードウェアリソースを仮想化して、ＶＭＭ１２０に見せていたとする。ＶＭＭ１１０は、このハードウェアリソースをエミュレーションするために、ＶＭＭ１２０がハードウェアリソースにアクセスしたら、ＶＭ－Ｅｘｉｔするように、ＶＭＣＳ７００の制御情報保持部７０３を設定する。一方、ＶＭＭ１２０は、このハードウェアリソースを仮想化せずにそのままゲストＯＳ１４０に見せるとする。すると、ｖＶＭＣＳ７１０の制御情報保持部７１３には、ゲストＯＳ１４０がこのハードウェアリソースにアクセスしてもＶＭ－Ｅｘｉｔするような設定はされない。しかし、実際にゲストＯＳ１４０を監視及び制御するのはＶＭＭ１１０であるため、ゲストＯＳ１４０がこのハードウェアリソースにアクセスしたら、ＶＭ－Ｅｘｉｔするように設定する必要がある。そのため、ＶＭＭ１１０がＶＭＭ１２０を監視及び制御するための設定と、ＶＭＭ１２０がゲストＯＳ１４０を監視及び制御するための設定とから、ＶＭＭ１１０がゲストＯＳ１４０を監視及び制御するための設定を作成することになる。
　以上の処理が終わると、ＶＭＭ１１０は、ＶＭ－Ｅｎｔｒｙ命令を実行し、ゲストＯＳ１４０へ処理を移す。
　逆に、ゲストＯＳ１４０で例外が発生してＶＭ－Ｅｘｉｔすると、ＶＭＭ１１０へ処理が戻る。ＶＭＭ１１０は、ＶＭ－Ｅｘｉｔ要因を特定し、ｖＶＭＣＳ７１０の制御情報保持部７１３に、ＶＭＭ１２０で処理するＶＭ－Ｅｘｉｔ要因として設定されたＶＭ－Ｅｘｉｔ要因と照合する。ＶＭＭ１２０で処理するＶＭ－Ｅｘｉｔ要因であった場合には、処理をＶＭＭ１２０へ移して、ＶＭＭ１２０に例外（ＶＭ－Ｅｘｉｔ要因に応じた処理）を処理させる。
　ＶＭＭ１２０へ例外を渡すために、ゲスト状態保持部７０２に保持されているｖＣＰＵ４２０の状態をｖＶＭＣＳ７１０のゲスト状態保持部７１２へコピーする。そして、ｖＶＭＣＳ７１０のホスト状態保持部７１１に保持されたｖＣＰＵ４１０の状態を、ＶＭＣＳ７００のゲスト状態保持部７０２へ設定する。制御情報保持部６０３に退避していた設定、及びＶＭ－Ｅｘｉｔに関する情報を、ＶＭＣＳ７００の制御情報保持部７０３へ設定する。最後に、ＶＭ－Ｅｎｔｒｙ命令を実行して、ＶＭＭ１２０へ処理を移す。
　ＶＭＭ１２０は、ＶＭＭ１１０からのＶＭ－Ｅｎｔｒｙにより、ゲストＯＳ１４０からＶＭ－Ｅｘｉｔした処理が移されたと判断し、そのＶＭ－Ｅｘｉｔ要因に応じた処理を行う。その処理が完了すると、処理をゲストＯＳ１４０へ戻すためのｖＶＭＣＳ７１０の設定及びＶＭ－Ｅｎｔｒｙ命令の実行を行う。これらは既に説明したように、ＶＭＭ１１０によるエミュレーションによってなされる。
　このように第２層のＶＭＭ１２０とゲストＯＳ１４０との間の状態遷移は、一度、第１層のＶＭＭ１１０を経由することで行われる。
＜ＣＰＵのＧＰＡ－ＨＰＡ変換＞
　ＣＰＵの仮想化支援機構には、ＣＰＵによるメモリアクセスのためのＧＰＡ－ＨＰＡ変換機能が用意されている。ＣＰＵのＧＰＡ－ＨＰＡ変換は、ＤＭＡＲと同様に、変換テーブルを用いて行われる。この変換テーブルは、ＧＰＡ－ＨＰＡ変換の他に、ＧＰＡの特定の領域をＷＰに設定するなどのメモリ属性の設定も行える。例えばインテル（登録商標）のＣＰＵの仮想化支援機構であるＶＴ－ｘでは、この変換テーブルをＥＰＴ（Extended Page Table）と呼ぶ。ＶＭＣＳ７００の制御情報保持部７０３には、このＥＰＴを登録する場所が用意されている。
　ＶＭＭ１１０がＶＭ１１１を動かす場合には、ＶＭ１１１のゲストメモリ空間のアドレスＧＰＡ１とホストメモリ空間のアドレスＨＰＡとの変換テーブルであるＥＰＴ９０１を作成して、ＶＭＣＳ７００の制御情報保持部７０３に設定する。一方、ＶＭＭ１２０がＶＭ１２１を動かす場合には、ＶＭ１２１のゲストメモリ空間のアドレスＧＰＡ２とＶＭＭ１２０のゲストメモリ空間ＧＰＡ１との変換テーブルであるＥＰＴ９１２を作成して、ｖＶＭＣＳ７１０の制御情報保持部７１３に設定する。
　ＶＭＭ１１０は、ＧＰＡ１－ＨＰＡの変換テーブルであるＥＰＴ９０１と、ＧＰＡ２－ＧＰＡ１の変換テーブルであるＥＰＴ９１２とから、ＧＰＡ２－ＨＰＡの変換テーブルであるＥＰＴ９０２を作成することが可能である。つまり、ＥＰＴ９０２は、ＶＭＭ１１０からゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙする際に、制御情報保持部７０３に設定される変換テーブルとなる。
＜ＤＭＡＲ－ＨＷの入れ子の仮想化＞
　前述した１階層でのＤＭＡＲ－ＨＷの仮想化とＣＰＵの仮想化支援機構の入れ子の仮想化とを組み合わせることにより、ＤＭＡＲ－ＨＷの入れ子の仮想化を実現できる。
　図７に、従来技術の入れ子の仮想化とＤＭＡＲ－ＨＷの仮想化とをそのまま組み合わせた場合のＤＭＡＲ－ＨＷの入れ子の仮想化の一例を示す。なお、図３に示す従来技術のＤＭＡＲ－ＨＷの仮想化、及び図６に示す入れ子の仮想化の例と同一の部分については、同一符号を付して、詳細な説明を省略する。以下、図７に示す構成を比較例という。
　図７の比較例に係る情報処理装置１５０は、ハードウェアリソースであるＣＰＵ４００、メモリ３００、ＤＭＡＲ－ＨＷ２００、及びＩ／Ｏデバイス８０１、８０２を備えている。情報処理装置１５０において、第１層のＶＭＭ１１０を動作させ、第１層のＶＭ１１１、１１２を構築している。さらに、ＶＭ１１１上で第２層のＶＭＭ１２０を動作させ、第２層のＶＭ１２１を構築し、ＶＭ１２１上でゲストＯＳ１４０を動作させている。なお、ＶＭＭ１１０が動作するホストメモリ空間をＨＰＡ、ＶＭＭ１２０が動作するゲストメモリ空間をＧＰＡ１、及びゲストＯＳ１４０が動作するゲストメモリ空間をＧＰＡ２とする。
　また、ＶＭ１１１には、ｖＤＭＡＲ－ＨＷ２１１が提供されると共に、ｖメモリ３１１及びｖＣＰＵ４１０が割り当てられている。また、ＶＭ１２１には、ｖＤＭＡＲ－ＨＷ２２１が提供されると共に、ｖメモリ３２１及びｖＣＰＵ４２０が割り当てられている。
　また、図８に、図７の構成のおけるメモリ３００の構成の一例を示す。メモリ３００のｖメモリ３１１に割り当てられた領域は、ｖメモリ３２１に割り当てられた領域を含む。ｖメモリ３２１に割り当てられた領域には、ゲストＯＳ１４０により作成されたＧＰＡ２基準のＤＭＡＲテーブル５２０が記憶される。また、ｖメモリ３１１に割り当てられた領域には、ＤＭＡＲテーブル５２０をＧＰＡ１基準に変換したＤＭＡＲテーブル５１２、ＶＭＭ１２０により作成されたＧＰＡ１基準のＤＭＡＲテーブル５１０が記憶される。さらに、ｖメモリ３１１に割り当てられた領域には、ｖＣＰＵ４１０の状態が保持されるｖＶＭＣＳ７１０、及びＧＰＡ２-ＧＰＡ１間の変換テーブルであるＥＰＴ９１２が記憶される。また、メモリ３００には、ＶＭＭ１１０によりＨＰＡ基準で作成されたＤＭＡＲテーブル５００、ＤＭＡＲテーブル５１０をＨＰＡ基準に変換したＤＭＡＲテーブル５０１、ＤＭＡＲテーブル５２０をＨＰＡ基準に変換したＤＭＡＲテーブル５０２が記憶される。また、メモリ３００には、ＣＰＵ４００の状態を保持するＶＭＣＳ７００、ＶＭＣＳ７００の状態が退避されるＶＭＣＳ－Ｃ６００が記憶される。また、メモリ３００には、ＧＰＡ１－ＨＰＡ間の変換テーブルであるＥＰＴ９０１、及びＧＰＡ２－ＨＰＡ間の変換テーブルであるＥＰＴ９０２が記憶される。
　また、図７に示すように、ＶＭＭ１１０は、ＶＭ－Ｅｘｉｔハンドラ１０、及びＤＭＡＲ仮想化部１１を備えている。さらに、ＤＭＡＲ仮想化部１１は、図９に示すように、ＧＰＡ１ＤＭＡＲテーブル取得部１２、ＧＰＡ１－ＨＰＡ変換部１３、ＷＰ設定部１４、ＤＭＡＲテーブル作成部１５、及びホストＤＭＡＲテーブル更新部１６を備えている。なお、ＶＭＭ１２０も、同様に、ＶＭ－Ｅｘｉｔハンドラ２０、及びＤＭＡＲ仮想化機能２１を備えており、ＶＭＭ１１０のＶＭ－Ｅｘｉｔハンドラ１０、及びＤＭＡＲ仮想化部１１と同様の機能が提供される。
　ＶＭ－Ｅｘｉｔハンドラ１０は、ゲストＯＳ１４０またはＶＭＭ１２０からのＶＭ－Ｅｘｉｔを捕捉し、ＶＭ－Ｅｘｉｔ要因を特定し、ＶＭ－Ｅｘｉｔ要因に応じた処理を行う。ＶＭ－Ｅｘｉｔ要因に応じた処理とは、例えば、ゲストＯＳ１４０またはＶＭＭ１２０へＶＭ－Ｅｎｔｒｙする際のＶＭＣＳに対する設定などである。また、ＶＭ－Ｅｘｉｔハンドラ１０は、ＶＭＭ１２０が、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５２０の領域をＷＰに設定するために、ＥＰＴ９１２を変更した際に、変更内容をＥＰＴ９０２へ反映する。
　ＧＰＡ１ＤＭＡＲテーブル取得部１２は、ＶＭＭ１２０が管理するＤＭＡＲテーブル５１０及びＤＭＡＲテーブル５１２を取得する。ＧＰＡ１－ＨＰＡ変換部１３は、ＧＰＡ１をＨＰＡへ変換する。ＷＰ設定部１４は、ＤＭＡＲテーブル５１０、５１２の領域をＷＰに設定する。ＤＭＡＲテーブル作成部１５は、ＧＰＡ１ＤＭＡＲテーブル取得部１２により取得されたＤＭＡＲテーブルをＧＰＡ１－ＨＰＡ変換したＤＭＡＲテーブルを作成する。ホストＤＭＡＲテーブル更新部１６は、ＤＭＡＲテーブル作成部１５により作成されたＤＭＡＲテーブルの内容でＤＭＡＲテーブル５００を更新する。
　次に、図１０～図１２を参照して、比較例におけるＤＭＡＲ－ＨＷの入れ子の仮想化処理について説明する。図１０は、ＶＭ－Ｅｘｉｔハンドラ１０による処理フローを示す。図１１は、ＶＭ－Ｅｘｉｔハンドラ１０による処理フロー内のＶＭ－Ｅｘｉｔ要因毎の処理（１）フローを示す。図１２は、ＤＭＡＲ仮想化部１１によるＤＭＡＲ仮想化処理フローを示す。
　図１０に示すＶＭ－Ｅｘｉｔハンドラ１０の処理フローのステップＳ１で、ＶＭ－Ｅｘｉｔハンドラ１０が、ゲストＯＳ１４０またはＶＭＭ１２０からのＶＭ－Ｅｘｉｔの要因を、ＶＭＣＳ７００の制御情報保持部７０３に仮想化支援機構４９０により自動で格納されるＶＭ－Ｅｘｉｔ要因を参照することにより、特定する。例えば、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２２１へＤＭＡＲテーブル５２０を設定する際には、ｖＤＭＡＲ－ＨＷ２２１のレジスタがマップされたアドレスへアクセスする。このアドレスへのアクセスで例外が発生するように、ＥＰＴ９０２に予め設定しておく。これにより、ＶＭ－Ｅｘｉｔ要因が特定のアドレスへのアクセス例外である場合に、ＶＭＣＳ７００の制御情報保持部７０３に格納される情報から、例外を起こしたアドレスを取得し、このアドレスがｖＤＭＡＲ－ＨＷ２２１のレジスタがマップされたアドレスに一致すれば、「ｖＤＭＡＲ－ＨＷ２２１への設定」と判定することができる。
　次に、ステップＳ２で、ＶＭ－Ｅｘｉｔハンドラ１０が、捕捉したＶＭ－ＥｘｉｔがゲストＯＳ１４０からのＶＭ－Ｅｘｉｔか、またはＶＭＭ１２０からのＶＭ－Ｅｘｉｔかを判定する。ゲストＯＳ１４０のＶＭ－Ｅｘｉｔの場合には、ステップＳ５５へ移行し、ＶＭＭ１２０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ１０へ移行する。
　ステップＳ５５では、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因に応じた処理を、そのままＶＭＭ１１０で行うか、またはＶＭＭ１２０へ任せるか、すなわち処理先を判定する。この判定は、ｖＶＭＣＳ７１０の制御情報保持部７１３に、ＶＭＭ１２０が処理するＶＭ－Ｅｘｉｔ要因を予め設定しておき、この設定を参照することにより行う。ＶＭ－Ｅｘｉｔ要因をＶＭＭ１１０で処理する場合には、ステップＳ２０へ移行し、ＶＭＭ１２０で処理する場合には、ステップＳ６１へ移行する。
　ステップＳ６１では、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭＭ１２０へ処理を移すための各種設定をＶＭＣＳへ行う。次に、ステップＳ６２で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭＭ１２０へ処理を移すために、ＶＭＭ１２０へＶＭ－Ｅｎｔｒｙする。
　一方、ステップＳ２０では、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因毎の処理（２）を実行する。ＶＭ－Ｅｘｉｔ要因毎の処理（２）とは、レジスタへの値の読み書きや命令の実行など、ＶＭＭ１１０が行うべき処理である。ＶＭ－Ｅｘｉｔ要因毎の処理（２）が終わると、ステップＳ２２へ移行し、ＶＭ－Ｅｘｉｔハンドラ１０が、ゲストＯＳ１４０へ処理を返すために、ゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙする。
　また、ステップＳ１０では、ＶＭ－Ｅｘｉｔハンドラ１０が、ステップＳ１で特定したＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令か否かを判定する。ＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令の場合には、ステップＳ２１へ移行し、ＶＭ－Ｅｘｉｔハンドラ１０が、ゲストＯＳ１４０へ処理を移すための各種設定をＶＭＣＳへ行う。次に、ステップＳ２２で、ＶＭ－Ｅｘｉｔハンドラ１０が、ゲストＯＳ１４０に処理を移すために、ゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙする。
　一方、上記ステップＳ１０で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因がＶＭ－Ｅｎｔｒｙ命令ではないと判定すると、ステップＳ３０へ移行し、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）を実行する。
　図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）のステップＳ３１で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因がｖＤＭＡＲ－ＨＷ２１１への設定か否かを判定する。ＶＭ－Ｅｘｉｔ要因がｖＤＭＡＲ－ＨＷ２１１への設定の場合には、ステップＳ１００へ移行し、ｖＤＭＡＲ－ＨＷ２１１への設定ではない場合には、ステップＳ３２へ移行する。
　ステップＳ３２では、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因がＷＰ設定されたＤＭＡＲテーブル５１０の更新か否かを判定する。ＶＭ－Ｅｘｉｔ要因がＷＰ設定されたＤＭＡＲテーブル５１０の更新の場合には、ステップＳ１００へ移行し、ＷＰ設定されたＤＭＡＲテーブル５１０の更新ではない場合には、ステップＳ３３へ移行する。
　ステップＳ１００では、ＤＭＡＲ仮想化部１１が、図１２に示すＤＭＡＲ仮想化処理を実行する。
　図１２に示すＤＭＡＲ仮想化処理のステップＳ１０１で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因がｖＤＭＡＲ－ＨＷ２１１への設定か否かを判定する。ＶＭ－Ｅｘｉｔ要因がｖＤＭＡＲ－ＨＷ２１１への設定の場合には、ステップＳ１０２へ移行し、ＶＭ－Ｅｘｉｔ要因がＷＰ設定されたＤＭＡＲテーブル５１０の更新の場合には、ステップＳ１１１へ移行する。
　ステップＳ１０２では、ＧＰＡ１ＤＭＡＲテーブル取得部１２が、ＶＭＭ１２０が作成したＤＭＡＲテーブル５１０を取得する。ＤＭＡＲテーブル５１０は、ＧＰＡ１基準に作成されている。そこで、次のステップＳ１０３で、ＤＭＡＲテーブル作成部１５が、ＧＰＡ１－ＨＰＡ変換部１３を利用して、ＧＰＡ１基準のＤＭＡＲテーブル５１０をＨＰＡ基準に変換したＤＭＡＲテーブル５０１を作成する。
　次に、ステップＳ１０４で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００のＩ／Ｏデバイス８０１に対する設定を、ＤＭＡＲテーブル５０１の内容で更新する。ステップＳ１０５で、ＶＭＭ１２０によるＤＭＡＲテーブル５１０の更新を検出できるように、ＷＰ設定部１４が、ＤＭＡＲテーブル５１０が記憶されたメモリ領域のＷＰ設定を、ＣＰＵ４００のＧＰＡ１－ＨＰＡ変換を行うＥＰＴ９０１に反映する。設定が終了すると、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）へリターンする。
　一方、ステップＳ１１１では、ＧＰＡ１ＤＭＡＲテーブル取得部１２が、ＶＭＭ１２０が作成したＤＭＡＲテーブル５１２を取得する。ＤＭＡＲテーブル５１２は、ＧＰＡ１基準に作成されている。そこで、次のステップＳ１１２で、ＤＭＡＲテーブル作成部１５が、ＧＰＡ１－ＨＰＡ変換部１３を利用して、ＧＰＡ１基準のＤＭＡＲテーブル５１２をＨＰＡ基準に変換したＤＭＡＲテーブル５０２を作成する。
　次に、ステップＳ１１３で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００のＩ／Ｏデバイス８０１に対する設定を、ＤＭＡＲテーブル５０２の内容で更新する。次に、ステップＳ１１４で、ＶＭＭ１２０によるＤＭＡＲテーブル５１２の更新を検出できるように、ＷＰ設定部１４が、ＤＭＡＲテーブル５１２が記憶されたメモリ領域のＷＰ設定を、ＣＰＵ４００のＧＰＡ１－ＨＰＡ変換を行うＥＰＴ９０１に反映する。設定が終了すると、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）へリターンする。
　上記ステップＳ３２で否定判定された場合は、ステップＳ３３へ移行し、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因に応じた処理を実行して、図１０に示すＶＭ－Ｅｘｉｔハンドラ１０による処理へリターンする。
　図１３に、ＤＭＡＲ－ＨＷの入れ子の仮想化処理における非特権モードと特権モードとの遷移を示す。なお、ここでは、ゲストＯＳ１４０にＩ／Ｏデバイス８０１が割り当てられ、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２２１に、Ｉ／Ｏデバイス８０１に対する設定を行う場合を示している。また、非特権モードから特権モードへのＶＭ－Ｅｘｉｔを一点鎖線の矢印、特権モードから非特権モードへのＶＭ－Ｅｎｔｒｙを二点鎖線の矢印で示している。
　図１３のステップＳ５００で、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２２１へのＤＭＡＲテーブル５２０の設定を行うため、ｖＤＭＡＲ－ＨＷ２２１のレジスタにアクセスすると、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。本来なら、ｖＤＭＡＲ－ＨＷ２２１を管理する第２層のＶＭＭ１２０へ処理を移したいが、ゲストＯＳ１４０及びＶＭＭ１２０は共に非特権モードであり、直接ＶＭ－Ｅｘｉｔすることはできないため、ゲストＯＳ１４０からＶＭＭ１１０へＶＭ－Ｅｘｉｔされる。
　次に、ステップＳ５０１で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因を特定する。ＶＭ－Ｅｘｉｔ要因は、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定であり、これは本来ＶＭＭ１２０の処理であるため、ステップＳ５０２で、ＶＭＭ１２０へ処理を移す。ステップＳ５０１→Ｓ５０２は、図１０のステップＳ１→Ｓ２→Ｓ５５→Ｓ６１→Ｓ６２に相当する。
　次に、ステップＳ５０３で、ＶＭＭ１２０のＶＭ－Ｅｘｉｔハンドラ２０が、ＶＭ－Ｅｘｉｔ要因を、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定であると特定する。次に、ステップＳ５０４で、ＶＭＭ１２０のＤＭＡＲ仮想化機能２１が、ＧＰＡ２空間を基準にして作成されたＤＭＡＲテーブル５２０を、ＧＰＡ１空間を基準に変換したＤＭＡＲテーブル５１２を作成する。次に、ステップＳ５０５で、ＤＭＡＲ仮想化機能２１が、ＤＭＡＲテーブル５１０をＤＭＡＲテーブル５１２の内容で更新する。ＤＭＡＲテーブル５１０が記憶されたメモリ領域はＷＰが設定されているため、ＤＭＡＲテーブル５１０の更新により例外が発生し、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。
　次に、ステップＳ５０６で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因を、ＷＰ設定されたＤＭＡＲテーブル５１０の更新であると特定する。次に、ステップＳ５０７で、ＧＰＡ１ＤＭＡＲテーブル取得部１２が、ＤＭＡＲテーブル５１２を取得する。そして、ＤＭＡＲテーブル作成部１５が、ＧＰＡ１－ＨＰＡ変換部１３を利用して、ＧＰＡ１基準のＤＭＡＲテーブル５１２をＨＰＡ基準に変換したＤＭＡＲテーブル５０２を作成する。
　次に、ステップＳ５０８で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００を、ＤＭＡＲテーブル５０２の内容で更新する。次に、ステップＳ５０９で、ＷＰ設定部１４が、ＤＭＡＲテーブル５１２が記憶されたメモリ領域をＷＰに設定する。次に、ステップＳ５１０で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭＭ１２０に処理を移すために、ＶＭＭ１２０へＶＭ－Ｅｎｔｒｙする。
　ステップＳ５０６→Ｓ５０７→Ｓ５０８→Ｓ５０９→Ｓ５１０は、図１０のステップＳ１→Ｓ２→Ｓ１０→Ｓ３０→図１１のＳ３１→Ｓ３２→Ｓ１００→図１２のＳ１０１→Ｓ１１１→Ｓ１１２→Ｓ１１３→Ｓ１１４→図１０のＳ６２に相当する。
　次に、ステップＳ５１１で、ＶＭＭ１２０が、ｖＣＰＵ４１０のＧＰＡ２－ＧＰＡ１変換を行うＥＰＴ９１２に、ゲストＯＳ１４０の作成したＤＭＡＲテーブル５２０が記憶されたメモリ領域のＷＰを設定する。
　次に、ステップＳ５１２で、ＶＭＭ１２０は、ゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙするための設定を、ｖＣＰＵ４１０のｖＶＭＣＳ７１０へ行う。ｖＶＭＣＳ７１０への設定は、特権命令であるＶＭＷＲＩＴＥまたはＶＭＲＥＡＤの実行を伴うため、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。
　次に、ステップＳ５１３で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因を、ｖＶＭＣＳ７１０へのＶＭＷＲＩＴＥまたはＶＭＲＥＡＤであると特定する。次に、ステップＳ５１４で、ＶＭ－Ｅｘｉｔハンドラ１０が、ｖＶＭＣＳ７１０及びＥＰＴ９０２への設定を行う。次に、ステップＳ５１５で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭＭ１２０に処理を移すために、ＶＭＭ１２０へＶＭ－Ｅｎｔｒｙする。ｖＶＭＣＳ７１０及びＥＰＴ９０２への設定では、ＶＭＭ１１０とＶＭＭ１２０との間で、ＶＭ－Ｅｘｉｔ及びＶＭ－Ｅｎｔｒｙが複数回繰り返されることになる。その設定の中で、ＶＭ－Ｅｘｉｔハンドラ１０は、ＥＰＴ９１２が変更されていることを検出すると、ＧＰＡ２－ＨＰＡ変換を行うＥＰＴ９０２へその変更を反映する。
　上記ステップＳ５１３→Ｓ５１４→Ｓ５１５は、図１０のステップＳ１→Ｓ２→Ｓ１０→Ｓ３０→図１１のＳ３１→Ｓ３２→Ｓ３３→図１０のＳ６１に相当する。
　次に、ステップＳ５１６で、ＶＭＭ１２０が、ゲストＯＳ１４０へ処理を戻すためにＶＭ－Ｅｎｔｒｙ命令を実行する。非特権モードのＶＭＭ１２０による特権命令ＶＭ－Ｅｎｔｒｙの実行により、例外が発生し、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。
　次に、ステップＳ５１７で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭ－Ｅｘｉｔ要因を、ＶＭＭ１２０からゲストＯＳ１４０へのＶＭ－Ｅｎｔｒｙ命令であると特定する。次に、ステップＳ５１８で、ゲストＯＳ１４０へ処理を移す。上記のステップＳ５１７→Ｓ５１８は、図１０のステップＳ１→Ｓ２→Ｓ１０→Ｓ２１→Ｓ２２に相当する。
　図１４に、ＤＭＡＲ－ＨＷの入れ子の仮想化におけるＤＭＡＲテーブルの関係の一例を示す。ＨＰＡのアドレス範囲４ＧＢ～１０ＧＢが、ＧＰＡ１の０ＧＢ～６ＧＢとして割り当てられている。さらにＧＰＡ１のアドレス範囲４ＧＢ～６ＧＢが、ＧＰＡ２の０ＧＢ～２ＧＢとして割り当てられている。ＧＰＡ２上に作成されたＤＭＡＲテーブル５２０には、ＧＰＡ２のアドレス範囲１ＧＢ～２ＧＢがＩ／Ｏデバイス８０１に割り当てられた領域であるとの設定が含まれる。ＤＭＡＲテーブル５２０をＧＰＡ１上に変換したものがＤＭＡＲテーブル５１２であり、ＤＭＡＲテーブル５１２をＨＰＡ上に変換したものがＤＭＡＲテーブル５０２である。ＤＭＡＲテーブル５０２には、ＨＰＡのアドレス範囲９ＧＢ～１０ＧＢがＩ／Ｏデバイス８０１に割り当てられた領域であるとの設定が含まれる。
　また、ＶＭＭ１２０により、ＧＰＡ１上に作成されたＤＭＡＲテーブル５１０をＨＰＡ上に変換したものがＤＭＡＲテーブル５０１である。
＜問題点＞
　以上説明したように、従来技術をそのまま組み合わせた比較例によるＤＭＡＲ－ＨＷの入れ子の仮想化では、図１３に示すように、特権モードと非特権モードとの間の遷移（ＶＭ－Ｅｎｔｒｙ及びＶＭ－Ｅｘｉｔ）が多いことが分かる。特権モードと非特権モードとの間の遷移回数が多い場合には、オーバヘッドが大きくなり、ゲストＯＳにＤＭＡＲ－ＨＷを提供する際の仮想化に時間を要することになる。
＜開示の技術の概要＞
　まず、上記の問題点を解決するための開示の技術の概念について説明する。比較例におけるＤＭＡＲ－ＨＷの入れ子の仮想化における第２層のＶＭＭ１２０の役割を考える。図１５の左図に示すように、ＶＭＭ１２０の役割は、ゲストＯＳ１４０の作成したＧＰＡ２基準のＤＭＡＲテーブル５２０をＧＰＡ１基準のＤＭＡＲテーブル５１２に変換して、ｖＤＭＡＲ－ＨＷ２１１へ設定することである。ｖＤＭＡＲ－ＨＷ２１１へ行われた設定は、第１層のＶＭＭ１１０が、ＤＭＡＲテーブル５１２をＨＰＡ基準のＤＭＡＲテーブル５０２に変換して、ＤＭＡＲ－ＨＷ２００へ反映する。
　つまり、ＶＭＭ１２０は、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５２０がＤＭＡＲ－ＨＷ２００へ設定されるまでの中継点にすぎない。ＶＭＭ１１０が直接ゲストＯＳ１４０のＤＭＡＲテーブル５２０をＤＭＡＲ－ＨＷ２００へ設定することができれば、第２層のＶＭＭ１２０を中継させる必要がない。
　この場合、ゲストＯＳ１４０がｖＤＭＡＲ－ＨＷ２２１を使用していることを、第２層のＶＭＭ１２０は知らないことになる。別の言い方をすれば、ＶＭＭ１２０は、ゲストＯＳ１４０がｖＤＭＡＲ－ＨＷ２２１を使用していないと認識することになる。つまり、第２層のＶＭＭ１２０は、上位のゲストＯＳ１４０の設定を意識することなく、自分の設定だけをｖＤＭＡＲ－ＨＷ２１１へ行えばよい。そして、ゲストＯＳ１４０及び第２層のＶＭＭ１２０のそれぞれが行ったＤＭＡＲの設定を、最終的に第１層のＶＭＭ１１０によりＤＭＡＲ－ＨＷ２００へ反映する。すなわち、図１５の右図に示すように、ＧＰＡ２基準のＤＭＡＲテーブル５２０を、ＶＭＭ１１０Ｂ（開示の技術の第１層のＶＭＭ）により直接ＨＰＡ基準のＤＭＡＲテーブル５０２へ変換する。
＜第１実施形態＞
　以下、開示の技術の第１実施形態の一例を、図面を参照して詳細に説明する。
　図１６に本第１実施形態に係る情報処理装置１００を示す。以下、図７に示す比較例と異なる点について説明する。図１６に示す第１実施形態では、情報処理装置１００で動作する第１層のＶＭＭ１１０Ｂが、ＶＭ－Ｅｘｉｔハンドラ１０Ｂ及びＤＭＡＲ仮想化部１１Ｂを備えている。なお、ＶＭ－Ｅｘｉｔハンドラ１０Ｂは、開示の技術の特定部の一例である。また、ＤＭＡＲ仮想化部１１Ｂは、開示の技術の設定部の一例である。
　ＶＭ－Ｅｘｉｔハンドラ１０Ｂは、ゲストＯＳ１４０またはＶＭＭ１２０からのＶＭ－Ｅｘｉｔを捕捉し、ＶＭ－Ｅｘｉｔ要因を特定する。ＶＭ－Ｅｘｉｔハンドラ１０Ｂは、ゲストＯＳ１４０からのＶＭ－Ｅｘｉｔについて、ＶＭ－Ｅｘｉｔ要因が「ＤＭＡＲ－ＨＷ２２１への設定」か、または「ＷＰ設定されたＤＭＡＲテーブル５２０の更新」であるかを判定する。ＶＭ－Ｅｘｉｔ要因が「ＤＭＡＲ－ＨＷ２２１への設定」または「ＷＰ設定されたＤＭＡＲテーブル５２０の更新」の場合は、処理をＶＭＭ１２０へ任せずにＶＭＭ１１０Ｂで実行する。
　上述したように、ＤＭＡＲ－ＨＷへのＤＭＡＲテーブルの設定は、メモリにマップされたＤＭＡＲ－ＨＷのレジスタへのアクセスにより行われる。ゲストＯＳ１４０によるメモリへのアクセスで例外が発生し、ＶＭ－Ｅｘｉｔした場合に、アクセスしたアドレスがゲストＯＳ１４０に見せているｖＤＭＡＲ－ＨＷ２２１のレジスタのアドレスに一致すれば、ＤＭＡＲ－ＨＷ２２１へのアクセスであると判定できる。すなわち、ｖＤＭＡＲ－ＨＷ２２１へのＤＭＡＲテーブル５２０の設定により、ＶＭ－Ｅｘｉｔしたと判定することができる。
　ここで、レジスタのアドレスへのアクセスを検出する場合には、第２層のＶＭＭ１２０がゲストＯＳ１４０に見せているｖＤＭＡＲ－ＨＷ２２１のレジスタのアドレスは、ＤＭＡＲ－ＨＷ２００のレジスタがマップされたアドレスと同じである必要がある。第２層のＶＭＭ１２０がゲストＯＳ１４０へ見せるｖＤＭＡＲ－ＨＷ２２１のレジスタのアドレスを自由に変えてしまうと、第１層のＶＭＭ１１０はそのアドレスを知るすべを持たないため、ｖＤＭＡＲ－ＨＷ２２１へのアクセスを検出することができない。
　ただし、ＶＭＭは、物理ＤＭＡＲ－ＨＷのレジスタのアドレスをそのまま上位のゲストに見せる（仮想化する）ことが一般的であるため、上記の制限は特に問題にはならない。
　また、ＷＰ設定されたＤＭＡＲテーブル５２０の更新は、メモリアクセスにより例外が発生した場合に、そのアドレスがＤＭＡＲテーブル５２０が記憶されている領域に一致するか否かにより判定することができる。
　図１７に示すように、ＤＭＡＲ仮想化部１１Ｂは、図９に示す比較例のＤＭＡＲ仮想化部１１の各機能部に、ＧＰＡ２ＤＭＡＲテーブル取得部１７及びＧＰＡ２－ＨＰＡ変換部１８が追加されている。
　ＧＰＡ２ＤＭＡＲテーブル取得部１７は、ＶＭ－Ｅｘｉｔ要因がゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定またはＤＭＡＲテーブル５２０の更新の場合に、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５２０を取得する。
　ＧＰＡ２－ＨＰＡ変換部１８は、ＧＰＡ２をＨＰＡへ変換する。ＧＰＡ２－ＨＰＡ変換部１８は、ＤＭＡＲテーブル作成部１５が、ゲストＯＳ１４０の作成したＤＭＡＲテーブル５２０をＨＰＡ基準に変換したＤＭＡＲテーブル５０２を作成する際に使用される。ＧＰＡ２－ＨＰＡ変換部１８は、ＣＰＵの仮想化支援機構のために作成したＧＰＡ２－ＨＰＡ変換を行うＥＰＴ９０２を使用する。
　また、本第１実施形態では、ＤＭＡＲテーブル５２０をＧＰＡ１基準に変換したＤＭＡＲテーブル５１２は作成されないため、図１８に示すように、メモリ３００には、図８の比較例のメモリ構成と異なり、ＤＭＡＲテーブル５１２を記憶する領域は設けられない。
　情報処理装置１００は、例えば図１９に示すように、ＣＰＵ４００、メモリ３００、及びＤＭＡＲ－ＨＷ２００に加え、不揮発性の記憶部６００、及び入出力インターフェース（Ｉ／Ｆ）８００を備えたサーバ４０で実現することができる。ＣＰＵ４００、メモリ３００、ＤＭＡＲ－ＨＷ２００、記憶部６００、及び入出力Ｉ／Ｆ８００は、バス４２を介して互いに接続されている。Ｉ／Ｏデバイス８０１、８０２は、入出力Ｉ／Ｆ８００を介してサーバ４０と接続されている。
　記憶部６００はＨＤＤ、フラッシュメモリ等によって実現できる。記録媒体としての記憶部６００には、サーバ４０を情報処理装置１００として機能させるための情報処理プログラム５０が記憶されている。ＣＰＵ４００は、情報処理プログラム５０を記憶部６００から読み出してメモリ３００に展開し、情報処理プログラム５０が有するプロセスを順次実行する。
　情報処理プログラム５０は、ＶＭ－Ｅｘｉｔハンドラプロセス５１、及びＤＭＡＲ仮想化プロセス５２を有する。ＣＰＵ４００は、ＶＭ－Ｅｘｉｔハンドラプロセス５１を実行することで、図１７に示すＶＭ－Ｅｘｉｔハンドラ１０Ｂとして動作する。また、ＣＰＵ４００は、ＤＭＡＲ仮想化プロセス５２を実行することで、図１７に示すＤＭＡＲ仮想化部１１Ｂとして動作する。これにより、情報処理プログラム５０を実行したサーバ４０が、情報処理装置１００として機能することになる。
　なお、ＣＰＵ４００により実現される各機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。
　次に、図２０及び図２１を参照して、本第１実施形態に係る情報処理装置１００の作用として、ＤＭＡＲ－ＨＷの入れ子の仮想化処理について説明する。図２０は、ＶＭ－Ｅｘｉｔハンドラ１０Ｂによる処理フローを示す。図２１は、ＤＭＡＲ仮想化部１１ＢによるＤＭＡＲ仮想化処理Ｂフローを示す。なお、図１０～図１２に示す比較例におけるＤＭＡＲ－ＨＷの入れ子の仮想化処理と同様の処理については、同一符号を付して、詳細な説明を省略する。
　図２０に示すＶＭ－Ｅｘｉｔハンドラ１０Ｂの処理フローのステップＳ１で、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、ＶＭ－Ｅｘｉｔを捕捉し、ＶＭ－Ｅｘｉｔ要因を特定する。
　次に、ステップＳ２で、ＶＭ－Ｅｘｉｔハンドラ１０が、トラップしたＶＭ－ＥｘｉｔがゲストＯＳ１４０からのＶＭ－Ｅｘｉｔか、またはＶＭＭ１２０からのＶＭ－Ｅｘｉｔかを判定する。ゲストＯＳ１４０のＶＭ－Ｅｘｉｔの場合には、ステップＳ５１へ移行し、ＶＭＭ１２０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ１０へ移行する。
　ステップＳ５１では、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、上記ステップＳ１で判定したＶＭ－Ｅｘｉｔ要因が、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定であるか否かを判定する。ｖＤＭＡＲ－ＨＷ２２１への設定の場合には、ＶＭＭ１１０で処理を続けるために、ステップＳ２０Ｂへ移行し、ｖＤＭＡＲ－ＨＷ２２１への設定ではない場合には、ステップＳ５２へ移行する。
　ステップＳ５２では、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、上記ステップＳ１で判定したＶＭ－Ｅｘｉｔ要因が、ゲストＯＳ１４０によるＷＰ設定されたＤＭＡＲテーブル５２０の更新か否かを判定する。ＷＰ設定されたＤＭＡＲテーブル５２０の更新の場合には、ＶＭＭ１１０で処理を続けるために、ステップＳ２０Ｂへ移行する。ＷＰ設定されたＤＭＡＲテーブル５２０の更新ではない場合には、ステップＳ５５へ移行する。
　ステップＳ２０Ｂでは、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、ＶＭ－Ｅｘｉｔ要因毎の処理（２Ｂ）を実行する。ＶＭ－Ｅｘｉｔ要因毎の処理（２Ｂ）は、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）と同様である。ただし、ステップＳ３１の「ｖＤＭＡＲ－ＨＷ２１１への設定」を「ｖＤＭＡＲ－ＨＷ２２１への設定」と読み替える。また、ステップＳ３２の「ＷＰ設定されたＤＭＡＲテーブル５１０の更新」を「ＷＰ設定されたＤＭＡＲテーブル５２０の更新」と読み替える。また、ステップＳ１００の「ＤＭＡＲ仮想化処理」を「ＤＭＡＲ仮想化処理Ｂ」と読み替える。さらに、Ｓ３０で実行される図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）においても、ステップＳ１００の「ＤＭＡＲ仮想化処理」を「ＤＭＡＲ仮想化処理Ｂ」と読み替える。
　図２１に示すＤＭＡＲ仮想化処理ＢのステップＳ１１０では、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、ＶＭ－Ｅｘｉｔ要因がゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定、またはＷＲ設定されたＤＭＡＲテーブル５２０の更新か否かを判定する。肯定判定の場合は、ステップＳ１２１へ移行する。一方、ＶＭ－Ｅｘｉｔ要因がＶＭＭ１２０によるｖＤＭＡＲ－ＨＷ２１１への設定、またはＷＰ設定されたＤＭＡＲテーブル５１０の更新の場合、ステップＳ１３１へ移行する。
　ステップＳ１２１では、ＧＰＡ２ＤＭＡＲテーブル取得部１７が、ゲストＯＳ１４０がアクセスしたアドレスに基づいて、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５２０を取得する。ＤＭＡＲテーブル５２０は、ＧＰＡ２基準で作成されている。そこで、次のステップＳ１２２で、ＤＭＡＲテーブル作成部１５が、ＧＰＡ２－ＨＰＡ変換部１８を利用して、ＧＰＡ２基準のＤＭＡＲテーブル５２０をＨＰＡ基準に変換したＤＭＡＲテーブル５０２を作成する。
　次に、ステップＳ１２３で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００のＩ／Ｏデバイス８０１に対する設定を、ＤＭＡＲテーブル５０２の内容で更新する。次に、ステップＳ１２４で、ゲストＯＳ１４０によるＤＭＡＲテーブル５２０の更新を検出できるように、ＷＰ設定部１４が、ＤＭＡＲテーブル５２０が記憶されたメモリ領域のＷＰ設定を、ＣＰＵ４００のＧＰＡ２－ＨＰＡ変換を行うＥＰＴ９０２に反映する。
　一方、ステップＳ１３１へ移行した場合には、ＧＰＡ１ＤＭＡＲテーブル取得部１２が、ＶＭＭ１２０がアクセスしたアドレスに基づいて、ＶＭＭ１２０が作成したＤＭＡＲテーブル５１０を取得する。ＤＭＡＲテーブル５１０は、ＧＰＡ１基準で作成されている。そこで、次のステップＳ１３２で、ＤＭＡＲテーブル作成部１５が、ＧＰＡ１－ＨＰＡ変換部１３を利用して、ＧＰＡ１基準のＤＭＡＲテーブル５１０をＨＰＡ基準に変換したＤＭＡＲテーブル５０１を作成する。
　次に、ステップＳ１３３で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００のＩ／Ｏデバイス８０１に対する設定を、ＤＭＡＲテーブル５０１の内容で更新する。次に、ステップＳ１３４で、ＶＭＭによるＤＭＡＲテーブル５１０の更新を検出できるように、ＷＰ設定部１４が、ＤＭＡＲテーブル５１０が記憶されたメモリ領域のＷＰ設定を、ＣＰＵ４００のＧＰＡ１－ＨＰＡ変換を行うＥＰＴ９０１に反映する。設定が終了すると、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（２Ｂ）へリターンする。
　図２２に、本第１実施形態でのＤＭＡＲ－ＨＷの入れ子の仮想化処理における非特権モードと特権モードとの遷移を示す。なお、ここでは、ゲストＯＳ１４０にＩ／Ｏデバイス８０１が割り当てられ、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２２１に、Ｉ／Ｏデバイス８０１に対する設定であるＤＭＡＲテーブル５２０を設定する場合を示している。また、非特権モードから特権モードへのＶＭ－Ｅｘｉｔを一点鎖線の矢印、特権モードから非特権モードへのＶＭ－Ｅｎｔｒｙを二点鎖線の矢印で示している。また、図１３に示す比較例でのＤＭＡＲ－ＨＷの入れ子の仮想化処理における非特権モードと特権モードとの遷移と同様の部分については、同一符号を付して、詳細な説明を省略する。
　図２２のステップＳ５００で、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２２１へのＤＭＡＲテーブル５２０の設定を行うため、ｖＤＭＡＲ－ＨＷ２２１のレジスタにアクセスすると、ＶＭＭ１１０へＶＭ－Ｅｘｉｔする。次に、ステップＳ５０１で、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、ＶＭ－Ｅｘｉｔ要因を特定する。
　次に、ステップＳ５２１で、ＶＭ－Ｅｘｉｔハンドラ１０Ｂが、ＶＭ－Ｅｘｉｔ要因が、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２２１への設定か、またはＷＰ設定されたＤＭＡＲテーブル５２０の更新か否かを判定する。ＶＭ－Ｅｘｉｔ要因がいずれかである場合には、処理をＶＭＭ１２０へ移すことなく、次のステップＳ５２２へ移行する。
　ステップＳ５２２では、ＧＰＡ２ＤＭＡＲテーブル取得部１７が、ＤＭＡＲテーブル５２０を取得する。そして、ＤＭＡＲテーブル作成部１５が、ＧＰＡ２－ＨＰＡ変換部１８を利用して、ＧＰＡ２基準のＤＭＡＲテーブル５２０をＨＰＡ基準に変換したＤＭＡＲテーブル５０２を作成する。
　次に、ステップＳ５０８で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００を、ＤＭＡＲテーブル５０２の内容で更新する。次に、ステップＳ５２３で、ＷＰ設定部１４が、ＤＭＡＲテーブル５２０が記憶されたメモリ領域のＷＰ設定をＥＰＴ９０２へ反映する。次に、ステップＳ５１８で、ゲストＯＳ１４０へ処理を移す。
　上記のステップＳ５０１→Ｓ５２１→Ｓ５２２→Ｓ５０８→Ｓ５２３→Ｓ５１８は、図２０のＳ１→Ｓ２→Ｓ５１（→Ｓ５２）→Ｓ２０Ｂ→図１１のＳ３１（→Ｓ３２）→Ｓ１００→図２１のＳ１２１→Ｓ１２２→Ｓ１２３→Ｓ１２４→図２０のＳ２２に相当する。
　図２３に、本第１実施形態でのＤＭＡＲ－ＨＷの入れ子の仮想化におけるＤＭＡＲテーブルの関係の一例を示す。図１４に示す比較例でのＤＭＡＲ－ＨＷの入れ子の仮想化におけるＤＭＡＲテーブルの関係と、メモリ領域の割り当ては同様である。ただし、本第１実施形態においては、ＤＭＡＲテーブル５２０をＧＰＡ１上に変換したＤＭＡＲテーブル５１２が作成されない点で相違する。
　以上説明したように、本第１実施形態の情報処理装置によれば、上位のゲストＯＳからのＶＭ－Ｅｘｉｔが、ＤＭＡＲ－ＨＷへのＤＭＡＲテーブルの設定または更新の場合には、第２層のＶＭＭに処理を移すことなく、第１層のＶＭＭで処理を行う。これにより、図２２を見ても明らかなように、非特権モードと特権モードとの遷移を減らすことができる。このため、入れ子の仮想化環境におけるゲストＯＳに、ＤＭＡＲ－ＨＷを提供する際の仮想化を高速化することができる。
＜第２実施形態＞
　次に、第２実施形態に係る情報処理装置について説明する。なお、第１実施形態に係る情報処理装置と同一の部分については、同一符号を付して、詳細な説明を省略する。
　図２４に示すように、第２実施形態に係る情報処理装置１０１は、ハードウェアリソースであるＣＰＵ４００、メモリ３００、ＤＭＡＲ－ＨＷ２００、及びＩ／Ｏデバイス８０１、８０２、８０３、８０４を備えている。ＣＰＵ４００は、８個のコア（コア４０１、４０２、・・・、４０８）を備えている。ＤＭＡＲ－ＨＷ２００は、Ｉ／Ｏデバイス８０１、８０２、８０３、８０４からのＤＭＡを制御する。
　ＶＭＭ１１０Ｂは、ＶＭ１１１、１１２を構築し、情報処理装置１０１のハードウェアリソースをＶＭ１１１とＶＭ１１２とに分割して割り当て、その状態を監視及び制御する。
　ＶＭ１１１には、コア４０１、・・・、４０４が割り当てられ、ＶＭ１１１のｖＣＰＵ４１１、・・・、４１４として動作させる。また、ＶＭ１１１には、メモリ３００の一部が、ｖメモリ３１１として割り当てられる。また、ＶＭ１１１には、Ｉ／Ｏデバイス８０１、８０２も直接割り当てられる。また、ＶＭ１１１には、ｖＤＭＡＲ－ＨＷ２１１が提供される。ＶＭ１１２には、コア４０５、・・・、４０８が割り当てられ、ＶＭ１１２のｖＣＰＵ４１５、・・・、４１８として動作させる。また、ＶＭ１１２には、メモリ３００の一部が、ｖメモリ３１２として割り当てられる。また、ＶＭ１１２には、Ｉ／Ｏデバイス８０３、８０４も直接割り当てられる。また、ＶＭ１１２には、ｖＤＭＡＲ－ＨＷ２１２が提供される。ｖＤＭＡＲ－ＨＷ２１１、２１２は、ＶＭＭ１１０Ｂによりエミュレーションされており、ｖＤＭＡＲ－ＨＷ２１１、２１２へのＤＭＡＲテーブルの設定は、ＤＭＡＲ－ＨＷ２００へ反映される。
　ＶＭ１１１の上では、第２層のＶＭＭ１２０が動作しており、ＶＭＭ１２０は、ＶＭ１１１上で動作するＶＭ１２１の状態を監視及び制御する。
　ＶＭ１２１には、ｖＣＰＵ４１１が割り当てられ、ＶＭ１２１のｖＣＰＵ４２１として動作する。また、ＶＭ１２１には、ｖメモリ３１１の一部が、ｖメモリ３２１として割り当てられる。また、ＶＭ１２１には、Ｉ／Ｏデバイス８０１も直接割り当てられる。また、ＶＭ１２１には、ｖＤＭＡＲ－ＨＷ２２１が提供される。なお、詳細は後述するが、ｖＤＭＡＲ－ＨＷ２２１は、ＶＭＭ１１０Ｂによりエミュレーションされており、ｖＤＭＡＲ－ＨＷ２２１へのＤＭＡＲテーブル５２０の設定は、ＤＭＡＲ－ＨＷ２００へ反映される。さらに、ＶＭ１２１の上では、ゲストＯＳ１４０が動作している。
　図２５にＶＭ１１１、１１２、１２１へのメモリの割り当てを示す。メモリ３００のメモリ空間（ＨＰＡ）の内、４ＧＢ～１２ＧＢの範囲をＶＭ１１１へ割り当て、１２ＧＢ～１６ＧＢの範囲をＶＭ１１２へ割り当てる。ＶＭ１１１に割り当てられたメモリ空間をＧＰＡ１１、ＶＭ１１２へ割り当てられたメモリ空間をＧＰＡ１２とする。また、ＨＰＡの０ＧＢ～２ＧＢの範囲は、ＶＭＭ１１０Ｂが使用し、２ＧＢ～４ＧＢの範囲は、ハードウェアのレジスタ等がマップされる領域とする。さらに、ＶＭ１１１のメモリ空間（ＧＰＡ１１）の内、４ＧＢ～８ＧＢの範囲をＶＭ１２１へ割り当てる。ＶＭ１２１へ割り当てられたメモリ空間をＧＰＡ２１とする。
　初めに、ＶＭＭ１１０ＢがＶＭ１１１、１１２を構築する際のＥＰＴ及びＤＭＡＲテーブルの設定について説明する。ＶＭＭ１１０Ｂは、ＶＭ上で動作するｖＣＰＵがメモリへアクセスする際に必要なＥＰＴ、及びＶＭに割り当てられたＩ／Ｏデバイスがメモリへアクセスする際に必要なＤＭＡＲテーブルをメモリ上に作成する。ＥＰＴ及びＤＭＡＲテーブルが記憶されるメモリ領域は、ＶＭＭ１１０Ｂ用に割り当てられた０～２ＧＢの範囲である。
　図２６に、メモリ３００に記憶されるＥＰＴ及びＤＭＡＲテーブルを示す。なお、メモリ３００には、上述したＶＭＣＳ等も記憶されるが、ここでは記載を省略している。ＥＰＴ９０１は、ＧＰＡ１１からＨＰＡへの変換を行うＥＰＴであり、ＶＭ１１１で動作するコア４０１、・・・、４０４のＶＭＣＳへ設定される。ＥＰＴ９２０は、ＧＰＡ１２からＨＰＡへの変換を行うＥＰＴであり、ＶＭ１１２で動作するコア４０５、・・・、コア４０８のＶＭＣＳへ設定される。
　図２７に、ＤＭＡＲ－ＨＷ２００に設定されるＤＭＡＲテーブル５００を示す。ここでは、Ｉ／Ｏデバイス８０１を、バス番号１０、デバイス番号１、及びファンクション番号０とする。この場合、Ｉ／Ｏデバイス８０１に対応するエントリは、ルートエントリテーブル５００Ａのバス番号１０のRoot entry１０を参照する。次に、Root entry１０からコンテキストエントリトテーブル５００Ｂ（Ｂｕｓ１０）を参照する。コンテキストエントリトテーブル５００Ｂ（Ｂｕｓ１０）のデバイス番号１及びファンクション番号０はContext entry ８に対応する。そして、Context entry ８はアドレス変換テーブル５００Ｃ１を参照している。アドレス変換テーブル５００Ｃ１は、ＧＰＡ１１からＨＰＡへ変換するテーブルである。
　同様に、Ｉ／Ｏデバイス８０２を、バス番号２０、デバイス番号２、及びファンクション番号０とする。また、Ｉ／Ｏデバイス８０３を、バス番号３０、デバイス番号３、及びファンクション番号０とする。また、Ｉ／Ｏデバイス８０４を、バス番号４０、デバイス番号４、及びファンクション番号０とする。さらに、アドレス変換テーブル５００Ｃ２を、ＧＰＡ１２からＨＰＡへ変換するテーブルであるとする。図２７の例では、ＶＭ１１１に割り当てられたＩ／Ｏデバイス８０１、８０２がアドレス変換テーブル５００Ｃ１を参照し、ＶＭ１１２に割り当てられたＩ／Ｏデバイス８０３、８０４がアドレス変換テーブル５００Ｃ２を参照していることが分かる。
　次に、ＶＭ１１１上で動作する第２層のＶＭＭ１２０が、ＶＭ１２１を構築する際に、ＥＰＴ及びＤＭＡＲテーブルの設定について説明する。具体的には、ＶＭＭ１２０は、ＶＭ１２１上で動作するｖＣＰＵ４２１によるｖメモリ３２１へのアクセスがｖメモリ３１１へのアクセスへ変換されるようにＥＰＴ９１２を作成する。ＥＰＴ９１２はＧＰＡ２１からＧＰＡ１１への変換を行うテーブルであり、ｖメモリ３１１上に作成される。ＥＰＴ９１２は、ｖＣＰＵ４１１のｖＶＭＣＳへ設定される。このｖＶＭＣＳへＥＰＴ９１２を設定するために、ＶＭＭ１２０は特権命令であるＶＭＷＲＩＴＥ命令を呼ぶ。しかし非特権モードで動作しているＶＭＭ１２０がＶＭＷＲＩＴＥ命令を呼ぶと、ＶＭ－Ｅｘｉｔが発生しＶＭＭ１１０Ｂへ処理が移る。
　ＶＭ１１０Ｂは、ＶＭ－Ｅｘｉｔ要因が、ｖＶＭＣＳへのＥＰＴ９１２の設定であることを特定すると、ＥＰＴ９０２を作成する。ＥＰＴ９０２はＧＰＡ２１からＨＰＡへの変換を行うテーブルである。ＥＰＴ９０２はＧＰＡ２１からＧＰＡ１１への変換を行うＥＰＴ９１２とＧＰＡ１１からＨＰＡへの変換を行うＥＰＴ９０１とを利用して作成される。
　また、ＶＭＭ１２０がｖＤＭＡＲ－ＨＷ２１１にＤＭＡＲテーブル５１０を設定する。ＤＭＡＲテーブル５１０は、ＶＭ１２１へ割り当てたＩ／Ｏデバイス８０１によるＤＭＡを、ＧＰＡ２１からＧＰＡ１１へ変換するためのものである。ＶＭＭ１２０が、ＤＭＡＲテーブル５１０を設定するために、ｖＤＭＡＲ－ＨＷ２１１のレジスタへアクセスすると、ＶＭ－Ｅｘｉｔが発生しＶＭＭ１１０Ｂへ処理が移る。
　ＶＭＭ１１０Ｂは、ＶＭ－Ｅｘｉｔ要因が、ｖＤＭＡＲ－ＨＷ２１１へのＤＭＡＲテーブル５１０の設定であることを特定すると、ＤＭＡＲテーブル５０１を作成する。図２８に、ＤＭＡＲテーブル５０１で更新したＤＭＡＲテーブル５００を示す。ＶＭＭ１２０が作成したＤＭＡＲテーブル５１０では、ＶＭ１２１へ割り当てられたＩ／Ｏデバイス８０１のＤＭＡをＧＰＡ２１からＧＰＡ１１へ変換する。一方、Ｉ／Ｏデバイス８０２は、ＶＭ１１１から他のＶＭへ割り当てられていないため、ＤＭＡＲテーブル５１０内のＩ／Ｏデバイス８０２に対応するエントリはパススルー設定である（ＶＭ１１１のメモリ空間を向いている）。ＤＭＡＲテーブル５０１では、Ｉ／Ｏデバイス８０１のＤＭＡをＧＰＡ２１からＨＰＡへ変換する。ＤＭＡＲテーブル５０１はＧＰＡ２１からＧＰＡ１１への変換を行うＤＭＡＲテーブル５１０内のアドレス変換テーブル５００Ｃ４とＧＰＡ１１からＨＰＡへの変換を行うＥＰＴ９０１とを利用して作成される。ＤＭＡＲテーブル５００のうち、ＶＭ１１１へ割り当てられたＩ／Ｏデバイス８０１、８０２の設定をＤＭＡＲテーブル５０１の内容で更新する。ＤＭＡＲテーブル５００内のＩ／Ｏデバイス８０１に対応するエントリは、アドレス変換テーブル５００Ｃ３を参照するように更新される。一方、ＤＭＡＲテーブル５００内のＩ／Ｏデバイス８０２に対応するエントリは、ＤＭＡＲテーブル５０１内のＩ／Ｏデバイス８０２に対応するエントリがパススルー設定であるため、アドレス変換テーブル５００Ｃ１を参照したままで、変更されない。
　ＤＭＡＲテーブル５００の更新が終わると、ＶＭＭ１２０によりＤＭＡＲテーブル５１０が更新されたことを検出できるように、ＶＭ１１０Ｂは、ＤＭＡＲテーブル５１０の作成されたメモリ領域のＷＰ設定をＥＰＴ９０１へ反映する。これらの設定が終わると、処理を戻すためにＶＭＭ１２０へＶＭ－Ｅｎｔｒｙする。
　ＶＭＭ１２０では、ｖＣＰＵ４２１を動かすための設定をｖＣＰＵ４１１のｖＶＭＣＳへ行う。上述したように、ｖＶＭＣＳへの設定は特権命令であるＶＭＲＥＡＤ／ＶＭＷＲＩＴＥの実行を伴うため、ＶＭ－ＥｘｉｔしてＶＭＭ１１０Ｂにより処理される。これらの設定が終了すると、ゲストＯＳ１４０へ処理を移すために、ＶＭ－Ｅｎｔｒｙ命令を実行する。
　非特権モードで動作しているＶＭＭ１２０が特権命令であるＶＭ－Ｅｎｔｒｙを呼び出すと、ＶＭ－Ｅｘｉｔし、処理がＶＭＭ１１０Ｂへ移る。ＶＭ１１０Ｂは、ＶＭ－Ｅｘｉｔ要因がＶＭ－Ｅｎｔｒｙ命令の呼び出しであることを特定すると、コア４０１のＶＭＣＳへＶＭ１２１を動作させるための設定を行い、ゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙする。
　ＶＭ１２１上で動作するゲストＯＳ１４０は、Ｉ／Ｏデバイス８０１のＤＭＡを制限するために、ｖＤＭＡＲ－ＨＷ２２１へＤＭＡＲテーブル５２０を設定する。例えば、図２９を参照して、Ｉ／Ｏデバイス８０１にＧＰＡ２１の０～２ＧＢの領域のみへのアクセスを許可するとの制限を設定する場合について説明する。ＤＭＡＲテーブル５２０のアドレス変換テーブル５００Ｃ６は、ＧＰＡ２１の０～２ＧＢ以外の範囲へのアクセスを拒絶する設定となる。
　ゲストＯＳ１４０は、ＤＭＡＲテーブル５２０をｖＤＭＡＲ－ＨＷ５２０へ設定するために、ｖＤＭＡＲ－ＨＷ２２１のレジスタへアクセスする。このアクセスで、ＶＭ－Ｅｘｉｔが発生する。ＶＭＭ１１０Ｂは、ＶＭ－Ｅｘｉｔ要因がｖＤＭＡＲ－ＨＷ２２１へのＤＭＡＲテーブル５２０の設定であることを特定すると、ＶＭＭ１２０へ処理を移すことなく、そのまま処理を進める。ＶＭＭ１１０Ｂは、ＧＰＡ２１空間のＤＭＡＲテーブル５２０をＨＰＡ空間へ変換したＤＭＡＲテーブル５０２を作成する。ＤＭＡＲテーブル５２０のアドレス変換テーブル５００Ｃ６は、ＧＰＡ２１からＨＰＡへの変換を行うＥＰＴ９０２を利用して、アドレス変換テーブル５００Ｃ５へ変換される。図２５に示すように、ＧＰＡ２１の０～２ＧＢの領域は、ＨＰＡの６ＧＢ～８ＧＢの領域に変換される。従って、アドレス変換テーブル５００Ｃ５は、ＧＰＡ２１の０～２ＧＢの領域にアクセスされた場合は、ＨＰＡの６ＧＢ～８ＧＢの領域へ変換し、それ以外の範囲へのアクセスを拒絶する設定となる。ＶＭＭ１１０Ｂは、ＤＭＡＲテーブル５００内のＩ／Ｏデバイス８０１に対応するエントリを、ＤＭＡＲテーブル５０２のアドレス変換テーブル５００Ｃ５を参照するように変更する。
　ＤＭＡＲテーブル５００の更新が終わると、ゲストＯＳ１４０によりＤＭＡＲテーブル５２０が更新されたことを検出できるように、ＶＭ１１０Ｂは、ＤＭＡＲテーブル５２０の作成されたメモリ領域のＷＰ設定をＥＰＴ９０２へ反映する。
　ＶＭＭ１１０Ｂは、処理をゲストＯＳ１４０へ戻すために、ＶＭ－Ｅｎｔｒｙ命令を実行する。
　以上のように、ＶＭ１２１上のゲストＯＳ１４０により、ＤＭＡＲ－ＨＷ２００が初期設定される。
　次に、ゲストＯＳ１４０によるＤＭＡＲ－ＨＷ２００に設定されているＤＭＡＲテーブル５００の更新について説明する。ここでは、図３０に示すように、ゲストＯＳ１４０が、Ｉ／Ｏデバイス８０１のアクセス可能なアドレス範囲をＧＰＡ２１の０～２ＧＢの範囲から、４ＧＢ～６ＧＢの範囲へ変更する場合を例に説明する。ＤＭＡＲテーブル５２０内のアドレス変換テーブル５００Ｃ８は、ＧＰＡ２１のアドレス範囲４ＧＢ～６ＧＢのみアクセス可能であることを示す設定である。ゲストＯＳ１４０は、アドレス変換テーブル５００Ｃ８を作成し、ＤＭＡＲテーブル５２０内のＩ／Ｏデバイス８０１に対応するエントリに参照させるように更新する。このとき、更新前のＤＭＡＲテーブル５２０の領域はＷＰ設定されているため、この更新によりＶＭ－Ｅｘｉｔが発生する。
　処理が移ったＶＭＭ１１０Ｂでは、ＶＭ－Ｅｘｉｔ要因が、ＤＭＡＲテーブル５２０内のＩ／Ｏデバイス８０１に対応するエントリの更新であることを特定すると、ＶＭＭ１２０へ処理を移すことなく、そのまま処理を進める。ＶＭＭ１１０Ｂは、ＤＭＡＲテーブル５２０内のＩ／Ｏデバイス８０１に対応するエントリが新しいアドレス変換テーブル５００Ｃ８を参照していることを特定する。そして、ＧＰＡ２１空間のアドレス変換テーブル５００Ｃ８をＨＰＡ空間へ変換したアドレス変換テーブル５００Ｃ７を作成し、ＤＭＡＲテーブル５０２内のＩ／Ｏデバイス８０１に対応するエントリに参照させる。また、ＤＭＡＲテーブル５００内のＩ／Ｏデバイス８０１に対応するエントリからも、アドレス変換テーブル５００Ｃ７を参照させる。アドレス変換テーブル５００Ｃ５がどのエントリからも参照されなくなった場合には、削除してもよい。そして、アドレス変換テーブル５００Ｃ６の使用していたメモリ領域のＷＰ設定を解除し、新たにアドレス変換テーブル５００Ｃ８の領域のＷＰ設定をＥＰＴ９０２へ反映する。
　以上のように、ＶＭ１２１上のゲストＯＳ１４０により、ＤＭＡＲ－ＨＷ２００に設定されたＤＭＡＲテーブル５００が更新される。
　最後に、ＶＭＭ１２０がＶＭ１２１を削除する場合のＤＭＡＲ－ＨＷ２００へのＤＭＡＲテーブル５００の設定について説明する。ＶＭ１２１を削除する際には、ＶＭ１２１に割り当てていたリソースを開放する。ＶＭ１２１に割り当てていたＩ／Ｏデバイス８０１も開放し、ＶＭＭ１２０の管理化へ置く。図３１に示すように、ＶＭＭ１２０の管理するＤＭＡＲテーブル５１０内のＩ／Ｏデバイス８０１に対応するエントリは、アドレス変換テーブル５００Ｃ４を参照している。そこで、この参照をパススルー設定に戻すために、ＤＭＡＲテーブル５１０内のＩ／Ｏデバイス８０１に対応するエントリを更新する。ＤＭＡＲテーブル５１０の領域はＷＰされているので、この更新によりＶＭ－Ｅｘｉｔが発生する。
　処理が移ったＶＭＭ１１０Ｂでは、ＶＭ－Ｅｘｉｔ要因がＤＭＡＲテーブル５１０内のＩ／Ｏデバイス８０１に対応するエントリの更新であることを特定し、このエントリがパススルー設定であることを検出する。そこで、ＶＭＭ１１０Ｂは、ＤＭＡＲテーブル５００内のＩ／Ｏデバイス８０１に対応するエントリに、ＧＰＡ１１－ＨＰＡ変換を行うアドレス変換テーブル５００Ｃ１を再び参照させる。もしアドレス変換テーブル５００Ｃ３がどのエントリからも参照されなくなった場合には、削除してもよい。そして、アドレス変換テーブル５００Ｃ４の使用していたメモリ領域のＷＰを解除するようにＥＰＴ９０１へ反映する。また、ＤＭＡＲテーブル５０２も、ＤＭＡＲテーブル５００から参照されなくなるため、削除してもよい。さらに、ＤＭＡＲテーブル５２０の使用していたメモリ領域のＷＰ設定を解除するようにＥＰＴ９０２へ反映する。
　以上のように、ＶＭ１２１の削除に伴う、ＤＭＡＲテーブル５００の更新が行われる。
＜第３実施形態＞
　次に、第３実施形態に係る情報処理装置について説明する。なお、第１実施形態及び第２実施形態に係る情報処理装置と同一の部分については、同一符号を付して、詳細な説明を省略する。
　図３２に示すように、第３実施形態に係る情報処理装置１０２のハードウェアリソースは第２実施形態に係る情報処理装置１０１と同様である。第３実施形態では、３層の仮想化を構成している。図２４に示す第２実施形態の構成と比較して、ＶＭ１２１上にＶＭＭ１３０が存在し、さらにＶＭＭ１３０上にＶＭ１３１が構築され、ＶＭ１３１上でゲストＯＳ１４０が動作している。ＶＭ１３１には、ｖＣＰＵ４３１及びｖメモリ３３１が割り当てられており、また、Ｉ／Ｏデバイス８０１も直接割り当てられている。さらに、ＶＭ１３１には、ｖＤＭＡＲ－ＨＷ２３１が提供されている。また、ゲストＯＳ１４０が動作するメモリ空間をＧＰＡ３とする。
　図３３に、図３２の構成のおけるメモリ３００に記憶されるＤＭＡＲテーブル及びＥＰＴを示す。なお、メモリ３００には、上述のＶＭＣＳも記憶されるが、ここでは記載を省略している。メモリ３００において、ｖメモリ３２１に割り当てられた領域の一部が、ｖメモリ３３１に割り当てられている点が、図１７に示す第１実施形態におけるメモリ３００構成と異なる。さらに、ｖメモリ３３１に割り当てられた領域には、ゲストＯＳ１４０により作成されたＧＰＡ３基準のＤＭＡＲテーブル５３０が記憶される。また、メモリ３００には、ＤＭＡＲテーブル５３０をＨＰＡ基準に変換したＤＭＡＲテーブル５０３が記憶される。また、メモリ３００には、ＧＰＡ３－ＨＰＡ間の変換テーブルであるＥＰＴ９０３が記憶される。
　ＶＭＭ１１０Ｃは、図３４に示すように、ＶＭ－Ｅｘｉｔハンドラ１０Ｃ、及びＤＭＡＲ仮想化部１１Ｃを備えている。さらに、ＤＭＡＲ仮想化部１１Ｃは、ＧＰＡ＃ｎＤＭＡＲテーブル取得部１７Ｃ、ＧＰＡ＃ｎ－ＨＰＡ変換部１８Ｃ、ＷＰ設定部１４、ＤＭＡＲテーブル作成部１５、及びホストＤＭＡＲテーブル更新部１６を備えている。
　ＧＰＡ＃ｎＤＭＡＲテーブル取得部１７Ｃは、指定されたＧＰＡ＃ｎ（ｎ＝１，２，３）基準で作成されたＤＭＡＲテーブル（ＤＭＡＲテーブル５１０、５２０、５３０）を取得する。ＧＰＡ＃ｎ－ＨＰＡ変換部１８Ｃは、指定されたＧＰＡ＃ｎ（ｎ＝１，２，３）を、ＧＰＡ＃ｎに対応するＥＰＴ９０１、９０２、９０３を使用して、ＨＰＡ基準のアドレスに変換する。
　次に、図３５～図３８を参照して、第３実施形態におけるＤＭＡＲ－ＨＷの入れ子の仮想化処理について説明する。図３５は、ＶＭ－Ｅｘｉｔハンドラ１０Ｃによる処理フローを示す。図３６は、ＶＭ－Ｅｘｉｔハンドラ１０Ｃによる処理フロー内のＶＭＭ１２０からのＶＭ－Ｅｘｉｔ処理フローを示す。図３７は、ＶＭ－Ｅｘｉｔハンドラ１０Ｃによる処理フロー内のＶＭＭ１３０からのＶＭ－Ｅｘｉｔ処理フローを示す。図３８は、ＤＭＡＲ仮想化部１１ＣによるＤＭＡＲ仮想化処理Ｃフローを示す。なお、図２０及び図２１に示す第１実施形態におけるＤＭＡＲ－ＨＷの入れ子の仮想化処理と同様の処理については、同一符号を付して、詳細な説明を省略する。
　図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理フローのステップＳ１で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ゲストＯＳ１４０、ＶＭＭ１２０、またはＶＭＭ１３０からのＶＭ－Ｅｘｉｔを捕捉する。そして、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、捕捉したＶＭ－ＥｘｉｔのＶＭ－Ｅｘｉｔ要因を特定する。
　次に、ステップＳ２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、捕捉したＶＭ－ＥｘｉｔがゲストＯＳ１４０からのＶＭ－Ｅｘｉｔか否かを判定する。ゲストＯＳ１４０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ５３へ移行し、ＶＭＭ１２０またはＶＭＭ１３０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ３へ移行する。
　ステップＳ５３では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、上記ステップＳ１で判定したＶＭ－Ｅｘｉｔ要因が、ゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２３１への設定であるか否かを判定する。ｖＤＭＡＲ－ＨＷ２３１への設定の場合には、ＶＭＭ１１０Ｃで処理を続けるために、ステップＳ２０Ｃへ移行し、ｖＤＭＡＲ－ＨＷ２３１への設定ではない場合には、ステップＳ５４へ移行する。
　ステップＳ５４では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、上記ステップＳ１で判定したＶＭ－Ｅｘｉｔ要因が、ゲストＯＳ１４０によるＷＰ設定されたＤＭＡＲテーブル５３０の更新か否かを判定する。ＤＭＡＲテーブル５３０の更新の場合には、ＶＭＭ１１０Ｃで処理を続けるために、ステップＳ２０Ｃへ移行し、ＤＭＡＲテーブル５３０の更新ではない場合には、ステップＳ５５へ移行する。
　ステップＳ２０Ｃでは、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因毎の処理（２Ｃ）を実行する。ＶＭ－Ｅｘｉｔ要因毎の処理（２Ｃ）は、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）と同様である。ただし、ステップＳ３１の「ｖＤＭＡＲ－ＨＷ２１１への設定」を「ｖＤＭＡＲ－ＨＷ２３１への設定」と読み替える。また、ステップＳ３２の「ＷＰ設定されたＤＭＡＲテーブル５１０の更新」を「ＷＰ設定されたＤＭＡＲテーブル５３０の更新」と読み替える。また、ステップＳ１００の「ＤＭＡＲ仮想化処理」を「ＤＭＡＲ仮想化処理Ｃ」と読み替える。
　一方、ステップＳ３では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、トラップしたＶＭ－ＥｘｉｔがＶＭＭ１２０からのＶＭ－Ｅｘｉｔか否かを判定する。ＶＭＭ１２０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ８０へ移行し、図３６に示すＶＭＭ１２０からのＶＭ－Ｅｘｉｔ処理を実行する。ＶＭＭ１３０からのＶＭ－Ｅｘｉｔの場合には、ステップＳ９０へ移行し、図３７に示すＶＭＭ１３０からのＶＭ－Ｅｘｉｔ処理を実行する。
　図３６に示すＶＭＭ１２０からのＶＭ－Ｅｘｉｔ処理のステップＳ１０では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ステップＳ１で特定したＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令か否かを判定する。ＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令の場合には、ステップＳ４１で、ＶＭ－Ｅｘｉｔハンドラ１０が、ＶＭＭ１３０へ処理を移すための各種設定をＶＭＣＳへ行う。次に、ステップＳ４２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭＭ１３０に処理を移すために、ＶＭＭ１３０へＶＭ－Ｅｎｔｒｙし、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理にリターンする。
　一方、上記ステップＳ１０で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因がＶＭ－Ｅｎｔｒｙ命令ではないと判定すると、ステップＳ３０へ移行し、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）を実行する。なお、ステップＳ１００の「ＤＭＡＲ仮想化処理」を「ＤＭＡＲ仮想化処理Ｃ」と読み替える。
　次に、ステップＳ６２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭＭ１２０に処理を移すために、ＶＭＭ１２０へＶＭ－Ｅｎｔｒｙし、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理にリターンする。
　図３７に示すＶＭＭ１３０からのＶＭ－Ｅｘｉｔ処理のステップＳ１０では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ステップＳ１で特定したＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令か否かを判定する。ＶＭ－Ｅｘｉｔ要因が、ＶＭ－Ｅｎｔｒｙ命令の場合には、ステップＳ２１で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ゲストＯＳ１４０へ処理を移すための各種設定をＶＭＣＳへ行う。次に、ステップＳ２２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ゲストＯＳ１４０に処理を移すために、ゲストＯＳ１４０へＶＭ－Ｅｎｔｒｙし、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理にリターンする。
　一方、上記ステップＳ１０で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因がＶＭ－Ｅｎｔｒｙ命令ではないと判定すると、ステップＳ５５へ移行する。ステップＳ５５では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因に応じた処理を、そのままＶＭＭ１１０Ｃで行うか、またはＶＭＭ１２０へ任せるかを判定する。ＶＭＭ１１０Ｃで処理する場合には、ステップＳ４０へ移行し、ＶＭＭ１２０で処理する場合には、ステップＳ６１へ移行する。
　ステップＳ６１では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭＭ１２０へ処理を移すための各種設定をＶＭＣＳへ行う。次に、ステップＳ６２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭＭ１２０に処理を移すために、ＶＭＭ１２０へＶＭ－Ｅｎｔｒｙし、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理にリターンする。
　一方、ステップＳ４０では、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因毎の処理（３）を実行する。ＶＭ－Ｅｘｉｔ要因毎の処理（３）は、図１１に示すＶＭ－Ｅｘｉｔ要因毎の処理（１）と同様である。ただし、ステップＳ３１の「ＤＭＡＲ－ＨＷ２１１への設定」を「ＤＭＡＲ－ＨＷ２２１への設定」と読み替える。また、ステップＳ３２の「ＷＰ設定されたＤＭＡＲテーブル５１０の更新」を「ＷＰ設定されたＤＭＡＲテーブル５２０の更新」と読み替える。また、ステップＳ１００の「ＤＭＡＲ仮想化処理」を「ＤＭＡＲ仮想化処理Ｃ」と読み替える。
　次に、ステップＳ４２で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭＭ１３０に処理を移すために、ＶＭＭ１３０へＶＭ－Ｅｎｔｒｙし、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理にリターンする。
　次に、図３８に示すＤＭＡＲ仮想化処理ＣのステップＳ１１０で、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因がゲストＯＳ１４０によるｖＤＭＡＲ－ＨＷ２３１への設定、またはＷＲ設定されたＤＭＡＲテーブル５３０の更新か否かを判定する。肯定判定の場合は、ステップＳ１４１へ移行し、否定判定の場合は、ステップＳ１２０へ移行する。
　ステップＳ１４１では、ＧＰＡ＃ｎＤＭＡＲテーブル取得部１７Ｃが、ゲストＯＳ１４０が作成したＤＭＡＲテーブル５３０を取得する。ＤＭＡＲテーブル５３０は、ＧＰＡ３基準で作成されている。そこで、次のステップＳ１４２で、ＤＭＡＲテーブル作成部１５が、ＧＰＡ＃ｎ－ＨＰＡ変換部１８Ｃを利用して、ＧＰＡ３基準のＤＭＡＲテーブル５２０をＨＰＡ基準に変換したＤＭＡＲテーブル５０３を作成する。
　次に、ステップＳ１４３で、ホストＤＭＡＲテーブル更新部１６が、ＤＭＡＲテーブル５００のＩ／Ｏデバイス８０１に対する設定を、ＤＭＡＲテーブル５０３の内容で更新する。次に、ステップＳ１４４で、ゲストＯＳ１４０によるＤＭＡＲテーブル５３０の更新を検出できるように、ＷＰ設定部１４が、ＤＭＡＲテーブル５３０が記憶されたメモリ領域のＷＰ設定を、ＣＰＵ４００のＧＰＡ３－ＨＰＡ変換を行うＥＰＴ９０３に反映する。
　一方、ステップＳ１２０へ移行した場合には、ＶＭ－Ｅｘｉｔハンドラ１０Ｃが、ＶＭ－Ｅｘｉｔ要因がＶＭＭ１３０によるｖＤＭＡＲ－ＨＷ２２１への設定、またはＷＲ設定されたＤＭＡＲテーブル５２０の更新か否かを判定する。肯定判定の場合は、ステップＳ１２１へ移行し、ＶＭ－Ｅｘｉｔ要因がＶＭＭ１２０によるｖＤＭＡＲ－ＨＷ２１１への設定、またはＷＲ設定されたＤＭＡＲテーブル５１０の更新の場合には、否定されて、ステップＳ１３１へ移行する。
　以下、図２１に示す第１実施形態におけるＤＭＡＲ仮想化処理Ｂと同様に、ステップＳ１２１～１２４、及び１３１～１３４を実行し、図３５に示すＶＭ－Ｅｘｉｔハンドラ１０Ｃの処理へリターンする。
　図３９に、第３実施形態でのＤＭＡＲ－ＨＷの入れ子の仮想化処理における非特権モードと特権モードとの遷移を示す。なお、ここでは、ゲストＯＳ１４０にＩ／Ｏデバイス８０１が割り当てられ、ゲストＯＳ１４０が、ｖＤＭＡＲ－ＨＷ２３１に、Ｉ／Ｏデバイス８０１に対する設定を行う場合を示している。また、非特権モードから特権モードへのＶＭ－Ｅｘｉｔを一点鎖線の矢印、特権モードから非特権モードへのＶＭ－Ｅｎｔｒｙを二点鎖線の矢印で示している。また、図２２に示す第１実施形態でのＤＭＡＲ－ＨＷの入れ子の仮想化処理における非特権モードと特権モードとの遷移と同様の部分については、同一符号を付して、詳細な説明を省略する。
　図３９に示すように、第３実施形態における非特権モードと特権モードとの遷移は、図２２に示す第１実施形態での非特権モードと特権モードとの遷移と同様である。４層以上の仮想化であっても、同様に開示の技術を適用することができる。４層以上の仮想化の場合も、上位のゲストＯＳによるＧＰＡ＃ｎ基準のＤＭＡＲテーブルの設定または更新を検出する。これらが検出された場合には、処理を上位のＶＭＭへ移すことなく、第１層のＶＭＭで、ＧＰＡ＃ｎ基準で作成されたＤＭＡＲテーブルをＨＰＡ基準のＤＭＡＲテーブルに変換すればよい。
　なお、上記では、ＣＰＵの仮想化支援機構及びＤＭＡＲ－ＨＷの仮想化支援機構の例として、インテル（登録商標）のＶＴ－ｘ及びＶＴ－ｄを例に説明したがこれに限定されない。ＣＰＵの仮想化支援機構は、ＣＰＵが特権モードと非特権モードとで動作するものであればよい。また、ＤＭＡＲ－ＨＷの仮想化支援機構は、変換表を用いてＤＭＡを行う機構であればよい。
　また、上記では開示の技術における情報処理プログラムの一例である情報処理プログラム５０が記憶部６００に予め記憶（インストール）されている態様を説明した。しかし、開示の技術における情報処理プログラムは、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。

Claims (10)

  1. 　第１層の仮想マシンモニタにより構築された仮想マシン上で動作する上位仮想マシンモニタにより上位仮想マシンが構築され、前記第１層の仮想マシンモニタが特権モードで動作し、前記上位仮想マシンモニタ及び前記上位仮想マシン上のゲストプログラムが非特権モードで動作する入れ子の仮想化環境において、前記ゲストプログラムの処理で発生した非特権モードから特権モードへの遷移の要因を特定する特定部と、
    　前記特定部により特定された要因が、前記上位仮想マシンに割り当てられた入出力装置によるＤＭＡのアドレス変換を設定された変換テーブルを用いて行うハードウェアのアドレス変換機構を仮想化して前記ゲストプログラムに提供される仮想変換機構で用いる仮想変換テーブルの設定または更新の場合に、前記仮想変換テーブル、及び前記ゲストプログラムが動作するゲストメモリ空間と前記第１層の仮想マシンモニタが動作するホストメモリ空間との対応関係に基づいて、前記変換機構で用いる前記変換テーブルを設定する設定部と、
    　を含む情報処理装置。
  2. 　前記設定部は、前記ゲストプログラムの処理が、前記仮想変換テーブルの設定または更新の場合に、非特権モードから特権モードへの遷移が発生するように、前記仮想変換機構及び前記仮想変換テーブルに対する処理が例外処理となるように設定する請求項１記載の情報処理装置。
  3. 　前記設定部は、前記ゲストメモリ空間のアドレスによる前記仮想変換テーブルを取得し、取得した前記仮想変換テーブルを、前記対応関係に基づいて、前記ホストメモリ空間のアドレスによる変換テーブルに変換して、前記変換機構で用いる前記変換テーブルとして設定する請求項１または請求項２記載の情報処理装置。
  4. 　第１の仮想マシンを構築し、特権モードで動作する第１層の仮想マシンモニタと、前記第１の仮想マシン上で非特権モードで動作し、第２の仮想マシンを構築する第２層の仮想マシンモニタと、前記第２の仮想マシン上で非特権モードで動作するゲストプログラムと
    を含む仮想化環境を動作させる処理装置と、
    　入出力装置と、
    　前記第２の仮想マシンに割り当てられた入出力装置によるＤＭＡのアドレス変換を設定された変換テーブルを用いて行うハードウェアのアドレス変換機構を仮想化して前記ゲストプログラムに提供される仮想変換機構で用いる仮想変換テーブルを格納する記憶装置とを備え、
    　前記処理装置が、
    　前記ゲストプログラムの処理で発生した非特権モードから特権モードへの遷移における前記仮想変換テーブルの設定または更新の処理を特定した場合に、前記仮想変換テーブル、及び前記ゲストプログラムが動作するゲストメモリ空間と前記第１層の仮想マシンモニタが動作するホストメモリ空間との対応関係に基づいて、前記変換機構で用いる前記変換テーブルを設定する
    　ことを特徴とする情報処理装置。
  5. 　コンピュータに、
    　第１層の仮想マシンモニタにより構築された仮想マシン上で動作する上位仮想マシンモニタにより上位仮想マシンが構築され、前記第１層の仮想マシンモニタが特権モードで動作し、前記上位仮想マシンモニタ及び前記上位仮想マシン上のゲストプログラムが非特権モードで動作する入れ子の仮想化環境において、前記ゲストプログラムの処理で発生した非特権モードから特権モードへの遷移の要因を特定し、
    　特定された要因が、前記上位仮想マシンに割り当てられた入出力装置によるＤＭＡのアドレス変換を設定された変換テーブルを用いて行うハードウェアの変換機構を仮想化して前記ゲストプログラムに提供される仮想変換機構で用いる仮想変換テーブルの設定または更新の場合に、前記仮想変換テーブル、及び前記ゲストプログラムが動作するゲストメモリ空間と前記第１層の仮想マシンモニタが動作するホストメモリ空間との対応関係に基づいて、前記変換機構で用いる前記変換テーブルを設定する
    　ことを含む処理を実行させる情報処理方法。
  6. 　前記コンピュータに、前記ゲストプログラムの処理が、前記仮想変換テーブルの設定または更新の場合に、非特権モードから特権モードへの遷移が発生するように、前記仮想変換機構及び前記仮想変換テーブルに対する処理が例外処理となるように設定することを含む処理を実行させる請求項５記載の情報処理方法。
  7. 　前記コンピュータに、前記ゲストメモリ空間のアドレスによる前記仮想変換テーブルを取得し、取得した前記仮想変換テーブルを、前記対応関係に基づいて、前記ホストメモリ空間のアドレスによる変換テーブルに変換して、前記変換機構で用いる前記変換テーブルとして設定することを含む処理を実行させる請求項５または請求項６記載の情報処理方法。
  8. 　コンピュータに、
    　第１層の仮想マシンモニタにより構築された仮想マシン上で動作する上位仮想マシンモニタにより上位仮想マシンが構築され、前記第１層の仮想マシンモニタが特権モードで動作し、前記上位仮想マシンモニタ及び前記上位仮想マシン上のゲストプログラムが非特権モードで動作する入れ子の仮想化環境において、前記ゲストプログラムの処理で発生した非特権モードから特権モードへの遷移の要因を特定し、
    　特定された要因が、前記上位仮想マシンに割り当てられた入出力装置によるＤＭＡのアドレス変換を設定された変換テーブルを用いて行うハードウェアの変換機構を仮想化して前記ゲストプログラムに提供される仮想変換機構で用いる仮想変換テーブルの設定または更新の場合に、前記仮想変換テーブル、及び前記ゲストプログラムが動作するゲストメモリ空間と前記第１層の仮想マシンモニタが動作するホストメモリ空間との対応関係に基づいて、前記変換機構で用いる前記変換テーブルを設定する
    　ことを含む処理を実行させるための情報処理プログラム。
  9. 　前記コンピュータに、前記ゲストプログラムの処理が、前記仮想変換テーブルの設定または更新の場合に、非特権モードから特権モードへの遷移が発生するように、前記仮想変換機構及び前記仮想変換テーブルに対する処理が例外処理となるように設定することを含む処理を実行させるための請求項８記載の情報処理プログラム。
  10. 　前記コンピュータに、前記ゲストメモリ空間のアドレスによる前記仮想変換テーブルを取得し、取得した前記仮想変換テーブルを、前記対応関係に基づいて、前記ホストメモリ空間のアドレスによる変換テーブルに変換して、前記変換機構で用いる前記変換テーブルとして設定することを含む処理を実行させる請求項８または請求項９記載の情報処理プログラム。
PCT/JP2013/061805 2013-04-22 2013-04-22 情報処理装置、方法、及びプログラム WO2014174580A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2015513387A JP5962853B2 (ja) 2013-04-22 2013-04-22 情報処理装置、方法、及びプログラム
PCT/JP2013/061805 WO2014174580A1 (ja) 2013-04-22 2013-04-22 情報処理装置、方法、及びプログラム
US14/883,679 US10162657B2 (en) 2013-04-22 2015-10-15 Device and method for address translation setting in nested virtualization environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/061805 WO2014174580A1 (ja) 2013-04-22 2013-04-22 情報処理装置、方法、及びプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/883,679 Continuation US10162657B2 (en) 2013-04-22 2015-10-15 Device and method for address translation setting in nested virtualization environment

Publications (1)

Publication Number Publication Date
WO2014174580A1 true WO2014174580A1 (ja) 2014-10-30

Family

ID=51791191

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/061805 WO2014174580A1 (ja) 2013-04-22 2013-04-22 情報処理装置、方法、及びプログラム

Country Status (3)

Country Link
US (1) US10162657B2 (ja)
JP (1) JP5962853B2 (ja)
WO (1) WO2014174580A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10027535B1 (en) * 2013-09-27 2018-07-17 Juniper Networks, Inc. Systems and methods for managing device configurations at various levels of abstraction
WO2015095352A1 (en) * 2013-12-17 2015-06-25 Sequitur Labs, Inc. Method and system for dynamic runtime selection and modification of conditional expressions in computations
CN106020985B (zh) * 2016-05-23 2019-08-30 北京北信源软件股份有限公司 数据处理方法、装置及服务器
US10241947B2 (en) * 2017-02-03 2019-03-26 Intel Corporation Hardware-based virtual machine communication
CN108388527B (zh) * 2018-02-02 2021-01-26 上海兆芯集成电路有限公司 直接存储器存取引擎及其方法
GB201807589D0 (en) 2018-05-10 2018-06-27 Nordic Semiconductor Asa Memory access
US20190042295A1 (en) * 2018-06-29 2019-02-07 Intel Corporation Timing compensation for a timestamp counter
US11360824B2 (en) 2019-11-22 2022-06-14 Amazon Technologies, Inc. Customized partitioning of compute instances
US11558311B2 (en) 2020-01-08 2023-01-17 Amazon Technologies, Inc. Automated local scaling of compute instances
US12020059B2 (en) * 2021-08-30 2024-06-25 International Business Machines Corporation Inaccessible prefix pages during virtual machine execution

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008165789A (ja) * 2006-12-27 2008-07-17 Intel Corp パーティション分割されたシステムにおいて、デバイスがメモリにアクセスするための、ゲスト・アドレスからホスト・アドレスへの変換
JP2009003749A (ja) * 2007-06-22 2009-01-08 Hitachi Ltd 仮想化プログラム及び仮想計算機システム
WO2012164716A1 (ja) * 2011-06-02 2012-12-06 株式会社日立製作所 仮想計算機の制御方法及び仮想計算機システム
JP2013508845A (ja) * 2009-10-21 2013-03-07 アーム・リミテッド データ処理システム内のハードウェア資源管理

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7395405B2 (en) * 2005-01-28 2008-07-01 Intel Corporation Method and apparatus for supporting address translation in a virtual machine environment
JP5369356B2 (ja) 2011-11-09 2013-12-18 株式会社日立製作所 仮想化プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008165789A (ja) * 2006-12-27 2008-07-17 Intel Corp パーティション分割されたシステムにおいて、デバイスがメモリにアクセスするための、ゲスト・アドレスからホスト・アドレスへの変換
JP2009003749A (ja) * 2007-06-22 2009-01-08 Hitachi Ltd 仮想化プログラム及び仮想計算機システム
JP2013508845A (ja) * 2009-10-21 2013-03-07 アーム・リミテッド データ処理システム内のハードウェア資源管理
WO2012164716A1 (ja) * 2011-06-02 2012-12-06 株式会社日立製作所 仮想計算機の制御方法及び仮想計算機システム

Also Published As

Publication number Publication date
JP5962853B2 (ja) 2016-08-03
US10162657B2 (en) 2018-12-25
JPWO2014174580A1 (ja) 2017-02-23
US20160034300A1 (en) 2016-02-04

Similar Documents

Publication Publication Date Title
JP5962853B2 (ja) 情報処理装置、方法、及びプログラム
US20230161615A1 (en) Techniques for virtual machine transfer and resource management
JP5870206B2 (ja) 効率的なメモリ及びリソース管理
JP5571208B2 (ja) パフォーマンスカウンタの仮想化
JP5459006B2 (ja) メモリ管理装置、メモリ管理方法及びメモリ管理プログラム
TWI537822B (zh) 虛擬化中斷優先順序及遞送之技術
JP5607474B2 (ja) コンピュータ・システムにおける入れ子式仮想化の性能改善
JP5541036B2 (ja) メモリアクセス制御プログラム、メモリアクセス制御方法、及び情報処理装置
US7506121B2 (en) Method and apparatus for a guest to access a memory mapped device
US20140337585A1 (en) Page table management
US20110197190A1 (en) Virtualization method and virtual machine
US10430221B2 (en) Post-copy virtual machine migration with assigned devices
US10268595B1 (en) Emulating page modification logging for a nested hypervisor
JP2017227969A (ja) 制御プログラム、システム、及び方法
JP6198858B2 (ja) 計算機、及び、ハイパバイザによる資源スケジューリング方法
JP2011523741A (ja) ホストデータ処理装置内におけるデバイスエミュレーションのサポート
JP5819350B2 (ja) 計算機システム及び起動方法
KR20220017949A (ko) 입력-출력 메모리 관리 유닛에 의한 게스트 운영 체제 버퍼 및 로그 액세스
US10922149B2 (en) System comprising a plurality of virtualization systems

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: 13882897

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015513387

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13882897

Country of ref document: EP

Kind code of ref document: A1