WO2020008757A1 - 仮想化環境におけるデバイスへのアクセス方法 - Google Patents

仮想化環境におけるデバイスへのアクセス方法 Download PDF

Info

Publication number
WO2020008757A1
WO2020008757A1 PCT/JP2019/021077 JP2019021077W WO2020008757A1 WO 2020008757 A1 WO2020008757 A1 WO 2020008757A1 JP 2019021077 W JP2019021077 W JP 2019021077W WO 2020008757 A1 WO2020008757 A1 WO 2020008757A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual
cpu
access
physical
resident
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2019/021077
Other languages
English (en)
French (fr)
Inventor
修一 小川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Corp
Original Assignee
Denso Corp
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 Denso Corp filed Critical Denso Corp
Publication of WO2020008757A1 publication Critical patent/WO2020008757A1/ja
Priority to US17/129,762 priority Critical patent/US12032983B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage

Definitions

  • the present disclosure relates to an access method for accessing a device in a virtual environment in which a virtual computer system is constructed.
  • a hypervisor operates on one piece of hardware, and a plurality of virtual computer systems operate on the hypervisor. This makes it possible to achieve high integration and high performance of the system, for example, such that a plurality of processes can be executed in parallel.
  • a virtual computer system is referred to as a virtual machine
  • a CPU included in hardware is referred to as a physical CPU
  • a device is referred to as a physical device
  • a CPU virtualized on the virtual machine is referred to as a virtual CPU
  • a device is referred to as a virtual device.
  • the virtual machine operates while accessing a physical device such as a storage or a network interface included in the hardware. At this time, on the virtual machine, the virtual CPU accesses the physical device by accessing the virtual device. Therefore, even when a plurality of virtual machines are constructed, each virtual machine can operate independently without special consideration of the existence of other virtual machines.
  • $ Virtio is configured such that a device driver on the hypervisor queues an access request from each virtual machine and returns a response to the request when access to the physical device is completed. Therefore, the request for access to the physical device and the response to the request are separated, and the period from when the access is requested to when the response is returned is in a so-called I / O wait state.
  • the changed virtual CPU can execute other tasks during the I / O waiting period.
  • GPU Graphics Processing Unit
  • the virtual CPU serving as the access source is executing the read / write instruction to the register of the GPU until the rendering is completed.
  • the waiting time is not changed.
  • An object of the present disclosure is to provide an access method capable of suppressing a decrease in performance when accessing a device of a type occupying an access source CPU in a virtual environment in which a virtual computer system is constructed on hardware. To provide.
  • a resident virtual CPU that is always assigned to a physical CPU and a non-resident virtual CPU that does not always have a physical CPU assigned to a virtual machine
  • the non-resident virtual CPU performs processing for accessing the virtual device.
  • the resident virtual CPU that is the original access source is released from the process of accessing the virtual device, and thus can execute other processes.
  • a non-resident virtual CPU that performs processing for accessing a virtual device is occupied by the virtual device on the virtual machine, but waits for a response from the physical device when viewed from the hypervisor. Is recognized as not working.
  • FIG. 1 is a diagram schematically illustrating an example of a virtualization environment according to the first embodiment.
  • FIG. 2 is a diagram schematically illustrating an example of an operation at the time of access and an allocation state of a physical CPU;
  • FIG. 3 is a diagram schematically illustrating an example of the virtualization environment according to the second embodiment.
  • the virtualization environment 1 of the present embodiment includes hardware 100, a hypervisor 200 operating on the hardware 100, and a plurality of virtual machines 300 operating on the hypervisor 200.
  • the CPU provided in the hardware 100 will be described as a physical CPU, the device as a physical device, the CPU virtualized on the virtual machine 300 as a virtual CPU, and the device as a virtual device.
  • the hardware 100 includes, for example, four pCPUs 101 to pCPU 104 corresponding to a physical CPU, a GPU 105 (Graphics Processing Unit) corresponding to a physical device, a Programmable Interrupt Controller (PIC) 106, a TIMER 107, and the like.
  • a CPU that contains four CPU cores in a single package is provided on the hardware 100, and these four CPU cores are treated as individual physical CPUs.
  • the pCPU 101 and the pCPU 102 are allocated to the virtual machine 300 of the VM0, and the pCPU 103 and the pCPU 104 are allocated to the virtual machine 300 of the VM1.
  • the GPU 105 has a function of processing drawing on the display 2 as is well known.
  • the GPU 105 processes drawing by transmitting a drawing request memory having a complicated structure to its own register.
  • this GPU 105 is difficult to distinguish between a request for access to the GPU 105 and a response, and has a dedicated interface having a type of occupying the accessing CPU during access to the register. Equivalent to a physical device.
  • the GPU 105 is also a shared device shared by the respective virtual machines 300.
  • the PIC 106 has a well-known function for controlling an interrupt generated on the hypervisor 200, such as setting of an interrupt from a physical device such as the GPU 105, enabling / disabling the interrupt, and setting of a CPU to which the interrupt is notified.
  • the TIMER 107 has a function of measuring various times required on the hypervisor 200, and is used for a known process such as a timer interrupt. Although illustration is omitted, on the hardware 100, for example, a storage device such as an embedded Multi Media Card (hereinafter, eMMC) or a physical device such as a communication device such as a Network Interface Card (hereinafter, NIC) is provided. Have been.
  • eMMC embedded Multi Media Card
  • NIC Network Interface Card
  • the hypervisor 200 is software that operates, for example, a plurality of virtual machines 300 by virtualizing the hardware 100 as is well known. In the present embodiment, it is assumed that the hypervisor 200 operates directly on the hardware 100 and the virtual machine 300 operates on the hypervisor 200, which is called a bare metal type or a native type.
  • the hypervisor 200 includes a hypervisor scheduler 201, a vGPU driver 202, and the like.
  • the hypervisor scheduler 201 is software that performs scheduling of each virtual machine 300 and the like.
  • the vGPU driver 202 is driver software for realizing a virtual device on the virtual machine 300.
  • a vGPU 305 which is a virtual device obtained by virtualizing the GPU 105, is realized on the virtual machine 300.
  • the $ vGPU driver 202 has an exclusive lock function 203 that exclusively processes access from each virtual machine 300.
  • the exclusive lock function 203 is shown as lock.
  • the vGPU driver 202 processes the access from each of the virtual machines 300 exclusively by the exclusive lock function 203 so that the access from each of the virtual machines 300 is possible. Control so that the physical device can be used correctly for the request.
  • driver software for other applications and other physical devices is also mounted on the hypervisor 200.
  • the virtual machine 300 is a virtual computer system that operates on the hypervisor 200.
  • the virtual machine 300 runs a virtual operating system (hereinafter, referred to as a virtual OS) on a virtual CPU, and performs various processing while accessing a virtual device. Is configured to execute.
  • a virtual OS virtual operating system
  • the two virtual machines 300, VM0 and VM1, constructed on the hypervisor 200 have the same configuration. Therefore, the following description will be made mainly with the virtual machine 300 of VM0 as an example. Note that it is also possible to construct virtual machines 300 having different configurations.
  • the virtual machine 300 includes vCPU301, vCPU302 and vCPU303 corresponding to virtual CPUs, vGPU305, vPIC306, vTIMER307 corresponding to virtual devices, and the like.
  • the vCPU 301 and the vCPU 302 correspond to resident virtual CPUs that are always assigned to the physical CPU and are operable
  • the vCPU 303 is not always assigned to the physical CPU, and It corresponds to a non-resident virtual CPU to which a CPU is assigned and becomes operable.
  • virtual CPUs that can always operate are mounted by the number of physical CPUs to be allocated.
  • Each virtual CPU has a cpumask indicating an assignable physical CPU.
  • identification information of a physical CPU that can be assigned is set, for example, as a bit string.
  • a value indicating that two physical CPUs of the pCPU 103 and the pCPU 104 can be assigned is set in the cpumask of the three virtual CPUs.
  • each virtual CPU on each virtual machine 300 is assigned a physical CPU so as not to overlap.
  • the physical CPUs are individually allocated to the virtual CPUs of the respective virtual machines 300, and it is possible to eliminate the possibility that the operation of each virtual machine 300 affects the performance of the other virtual machine 300.
  • cpumask is a value for identifying a physical CPU that can be allocated, and the hypervisor scheduler 201 manages which physical CPU is actually allocated.
  • a task activation process 308 for activating various tasks T0 to TN and an OS scheduler 309 for scheduling the activated tasks are mounted on the virtual machine 300.
  • a virtual driver which is driver software for accessing a virtual device is mounted on the virtual machine 300.
  • a graphic driver 310 for accessing the vGPU 305 is assumed.
  • driver software for another virtual device is also installed.
  • ⁇ Cpumaskv ⁇ is set for each task by the task activation process 308.
  • identification information such as the number of a virtual CPU that can execute the task is set.
  • the graphic driver 310 is for accessing the vGPU 305 which is a dedicated virtual device, and includes a system call unit 311 having an access part (s) for accessing the virtual device, and an interrupt handler unit having an access part (i). 312. Note that the operations of the system call unit 311 and the interrupt handler unit 312 are well known, and a description thereof will be omitted.
  • the graphic driver 310 has a cpumask change process 313 and an IRQmask setting process 314.
  • the cpumask change process 313 is a process for changing the cpumask set in the task, which will be described in detail later.
  • the IRQmask setting process 314 includes an IRQmask 315 indicating a virtual CPU that operates the interrupt handler unit 312. This is the process for setting.
  • the interrupt handler unit 312 is set by the IRQ mask setting process 314 so that it operates only by the vCPU 303.
  • the hypervisor 200 operates the virtual machines 300 in parallel while using the hypervisor scheduler 201, the physical CPU, the PIC 106, the TIMER 107, and the like.
  • the CPU is set and the physical CPUs are individually allocated to the respective virtual machines 300 so as not to be affected by the other virtual machines 300. In addition, it does not affect other virtual machines 300.
  • the hypervisor scheduler 201 refers to the cpumask of the vCPU 301 and the vCPU 302 to change the pCPU 101 to the vCPU 301, for example.
  • Assignment, pCPU 102 is assigned to vCPU 302.
  • the operating state means a state in which some processing is allocated to the virtual CPU.
  • the virtual CPU becomes operable.
  • the hypervisor 200 allocates the pCPU 101 or the pCPU 102 to the vCPU 303, and during that period, either the vCPU 301 or the vCPU 302 is in a state of waiting for a physical CPU.
  • the hypervisor 200 allows the virtualized environment 1 to operate efficiently by assigning the physical CPUs to the virtual CPUs as evenly as possible.
  • each virtual machine 300 can operate with the same performance as an OS having two physical CPUs, and simultaneous execution of a plurality of tasks is realized in the same manner as a normal OS without using the hypervisor 200. I have.
  • each virtual machine 300 may share and access the GPU 105 on the hardware 100 or the above-mentioned physical device such as eMMC or NIC. Therefore, in the virtualization environment 1, for example, by operating the vGPU driver 202 on the hypervisor 200 and implementing a virtual device on the virtual machine 300, each virtual machine 300 can access as an independent device. And
  • the hardware 100 includes one physical device
  • access requests from a plurality of virtual machines 300 are exclusively processed in a time-sharing manner.
  • the virtual machine 300 enters the exclusion waiting state. Therefore, a virtualization technique such as the above-described virtual exists.
  • the virtual CPU is occupied during access to the occupation type device and cannot be switched to another task, but the physical CPU is not performing any processing.
  • the performance of the virtual environment 1 is prevented from deteriorating.
  • the access method according to the present embodiment will be described by taking as an example a case where a request for access to the GPU 105 is issued from the task T0 activated on the virtual machine 300.
  • an application has a process space and is sometimes called a thread.
  • an application or an application executed inside the OS may be used.
  • a program unit that can be executed simultaneously is called a task.
  • the task T0 is allocated to the vCPU 301 or the vCPU 302 according to the setting of cpumaskv.
  • the task T0 is activated at time t0 and the task T0 is assigned to the vCPU 301.
  • the pCPU 101 is assigned as a physical CPU to the vCPU 301 executing the task T0, as shown in the assignment state of the physical CPU in FIG.
  • the thick lines provided corresponding to the respective tasks indicate that the physical CPUs are allocated.
  • the system call section 311 When the graphic driver 310 is called by executing the task T0, the system call section 311 operates in the task T0. First, the system call unit 311 executes a cpumask change process 313 that changes the cpumaskv0 of the task T0 so that it can be executed only by the vCPU 303. In this cpumask change processing 313, when it is confirmed that cpumaskv0 has been changed to a value that does not include the vCPU 301 and vCPU 302, the CPU scheduler 309 is instructed to reassign the task T0 to the vCPU 303 that has become able to execute the task T0. Is issued.
  • the vCPU 303 When an instruction is issued to the OS scheduler 309, the vCPU 303 temporarily enters a waiting state when the vCPU 303 is being used for another task. However, when the vCPU 303 is not used or the waiting state ends, the vCPU 303 The task T0 is assigned, and the vCPU 303 enters the operating state. Since the operating state of the virtual CPU is checked by the hypervisor scheduler 201 on the hypervisor 200, the hypervisor scheduler 201 also detects that the vCPU 303 has become active.
  • the hypervisor scheduler 201 that has detected that the vCPU 303 has become active sets the vCPU 303 in addition to the vCPU 301 and the vCPU 302 as a physical CPU allocation target. In this state, three virtual CPUs temporarily operate on the two physical CPUs. For example, if the pCPU 101 is assigned to the vCPU 303 at time t1 in FIG. 2, the vCPU 301 to which the pCPU 101 has been assigned until then. Temporarily enters a state of waiting for a physical CPU. That is, at time t1, the virtual CPU executing the task T0 is switched from the vCPU 301 to the vCPU 303.
  • the system call unit 311 becomes operable with the vCPU 303, so that the processing of the system call unit 311 can be continued on the vCPU 303. Therefore, the system call unit 311 calls the access part (s), and the access part (s) accesses the register of the vGPU 305. Although the access to the vGPU 305 is transmitted to the vGPU driver 202 on the hypervisor 200, the access is temporarily suspended by the exclusive lock function 203 in order to wait for the execution of another virtual machine 300 or to prepare for accessing the GPU 105. At this time, the vCPU 303 enters a standby state waiting for lock release.
  • the hypervisor scheduler 201 cancels the assignment of the pCPU 101 to the vCPU 303 that is in the standby state and is not performing any processing, and reassigns the pCPU 101 to the vCPU 301 that is in the physical CPU waiting state to assign the vCPU 301.
  • Operable state When the vCPU 301 becomes operable, for example, the task T1 can be executed by the vCPU 301 on the virtual machine 300.
  • the vCPU 303 is in the standby state, so that the allocation of the physical CPUs can be released.
  • two vCPUs 301 and 302 can be substantially released.
  • Two virtual CPUs can be exclusively used by one virtual CPU. Therefore, even if access to the register of the access part (s) is delayed or access takes time, the performance of the entire virtualization environment 1 is substantially reduced to two virtual CPUs. This is equivalent to a state where one physical CPU is allocated, and the performance of the virtualization environment 1 can be maintained.
  • the vGPU driver 202 releases the lock waiting for exclusion and terminates the access to the GPU 105, the result is returned to the access part (s), so that the task T0 is in an operable state, more specifically.
  • the suspended access part (s) is in a state where the operation can be resumed.
  • the hypervisor scheduler 201 that has detected that the task T0 is in an operable state is reviewed after a predetermined scheduling time by the hypervisor scheduler 201. Is assigned. Thereby, the access part (s) resumes the operation.
  • cpumaskv0 is changed by the cpumask change processing 313 to a value that permits execution by the vCPU 301 and vCPU 303 but does not permit execution by the vCPU 303. That is, cpumaskv0 is returned to the original value.
  • the task T0 waits for the operation of the vCPU 301 or vCPU 302, and the vCPU 303 does not perform any processing.
  • the hypervisor scheduler 201 operates to release the physical CPU from the vCPU 303 that has not performed any processing, and to allocate the physical CPU to the vCPU 301 and the vCPU 302.
  • the vCPU 301 and the vCPU 302 return the pCPU 101 and the pCPU 102 to a state where they can be used full time.
  • the task T0 was not in a standby state but was operating on the vCPU 303. Since the OS scheduler 309 cannot switch from the task in the operating state to another task, conventionally, the vCPU 301 that was executing the task T0 could not execute the other task.
  • the execution subject of the task T0 is switched from the vCPU 301 to the vCPU 303 by the cpumask change process 313. That is, the processing for accessing the vGPU 305 is performed by the vCPU 303.
  • the hypervisor scheduler 201 does not assign a physical CPU to the vCPU 303 and And a physical CPU are assigned to the vCPU 302.
  • the vCPU 303 which is a non-resident virtual CPU, is provided so that the vCPU 303 waits for the completion of the operation of the vGPU 305 and enters a standby state.
  • the vCPU 301 can be released from the task T0, and another vCPU 301 can Tasks can be executed, and efficient operation of the entire virtualization environment 1 has become possible.
  • the system call unit 311 of the graphic driver 310 may fulfill the purpose of the system call only by accessing the register of the vGPU 305, or may access the register after waiting for a change in the state of the vGPU 305.
  • the system call unit 311 records the contents of the request on the memory, sets to operate when the state of the vGPU 305 changes, and ends the processing.
  • the status change of the vGPU 305 is notified by an interrupt.
  • the PIC 106 notifies the hypervisor scheduler 201 of an interrupt.
  • the notified interrupt is processed by the vCPU 303 because the vCPU 303 is set by the IRQmask 315 of the vPIC 306. Therefore, the hypervisor scheduler 201 assigns a physical CPU to the vCPU 303 to operate the interrupt handler unit 312 of the vCPU 303.
  • the access part (i) accesses the register of the vGPU 305 by operating the interrupt handler unit 312, the access to the vGPU 305 is transmitted to the vGPU driver 202 on the hypervisor 200, but the waiting of the execution of another virtual machine 300 or The exclusive lock function 203 temporarily waits for preparation for accessing the GPU 105.
  • the vCPU 303 enters a standby state waiting for lock release.
  • the hypervisor scheduler 201 releases the assignment of the physical CPU to the vCPU 303 in the exclusion waiting state, and assigns the physical CPU to the vCPU 301 and the vCPU 302 to operate. This makes it possible to make other tasks on the virtual machine 300 operable even while the access unit (i) waits for access to the register.
  • the access part (i) resumes operation, and the GPU 105 can be accessed via the vGPU driver 202.
  • the vCPU 303 becomes empty, and the hypervisor scheduler 201 performs only the processing of the vCPU 301 and the vCPU 302.
  • the processing of the access part (s) and the access part (i) is performed by the non-resident vCPU 303, so that the access to the register is waited and the access source CPU is occupied. Even in such a case, an access method is employed in which another task can operate on a resident virtual CPU.
  • the access method is such that, in the virtual machine 300, a resident virtual CPU (vCPU 301 and vCPU 302) to which a physical CPU is always allocated and a non-resident virtual CPU to which a physical CPU is not always allocated.
  • a resident virtual CPU accesses a virtual device corresponding to an occupied physical device, the CPU (vCPU 303) is mounted on behalf of the non-resident virtual CPU.
  • the processing is transferred from the resident virtual CPU that is the access source to the non-resident virtual CPU, and even if the non-resident virtual CPU becomes occupied during access, other tasks are performed in the resident virtual CPU. Can be executed.
  • the non-resident virtual CPU that has become the occupied state during access enters a standby state in which substantially no processing is performed, the assignment of the physical CPU can be released, and the task to the occupied device can be continued. In this state, a physical CPU can be assigned to the resident virtual CPU to execute other tasks.
  • the physical CPU can be effectively used, and in the virtualization environment 1 in which a virtual computer system is built on the hardware 100, the occupied device is Can be prevented from deteriorating when accessing the URL.
  • the register access in the system call request is assumed to be performed when the system call is extended, and when the interrupt is extended, the above access method can be applied in any case.
  • the physical CPU can be effectively used when accessing the device.
  • the non-resident virtual CPU since it is not a target of physical CPU allocation unless it is in the operating state, it is different from a configuration in which three resident virtual CPUs are simply provided and three virtual CPUs are scheduled in time series. Also, the performance of the virtual environment 1 is not affected. Therefore, this is particularly significant when the virtual environment 1 is required to have real-time properties.
  • driver software for accessing an occupied virtual device includes a system call unit 311 and an interrupt handler unit 312, and includes the system call unit 311 and the interrupt handler unit 312.
  • Each of them implements a virtual driver provided with an access part for accessing a virtual device, and when accessing a dedicated virtual device from a resident virtual CPU, at least the access part (s, i) is a non-resident virtual CPU.
  • An access method acting on behalf of the CPU can be employed.
  • each virtual machine 300 adopts the above-described access method, thereby allowing each virtual machine 300 to operate. Performance can be maintained.
  • each virtual machine 300 By operating two or more virtual machines 300 on the hypervisor 200 and allocating physical CPUs to the plurality of virtual machines 300 so as not to overlap, more strictly, each virtual machine 300 By allocating the physical CPUs to the virtual CPUs so as not to overlap each other, it can be expected that the performance of the virtualization environment 1 will be the highest.
  • the configuration in which the hardware 100 includes one occupation-type physical device has been described.
  • the hardware 100 includes a plurality of occupation-type physical devices the occupancy of the hardware 100 is limited.
  • the above-described access method can be adopted.
  • the number of resident virtual CPUs can be larger than the number of physical CPUs allocated to the virtual machine 300 if necessary. Even in such a configuration, by separately providing a non-resident virtual CPU, it is possible to suppress a decrease in performance when accessing a dedicated device.
  • the second embodiment differs from the first embodiment in that the access part (s) operated by the system call unit 311 is a dedicated task.
  • the virtualization environment 1 of the present embodiment includes hardware 100, a hypervisor 200 operating on the hardware 100, and a plurality of virtual machines 300 operating on the hypervisor 200.
  • the hypervisor 200 operates on the hardware 100, and two virtual machines 300 of VM0 and VM1 operate on the hypervisor 200.
  • the hardware 100 includes four pCPUs 101 to 104 corresponding to physical CPUs, a GPU 105 corresponding to a physical device, a PIC 106, and a TIMER 107.
  • pCPU101 and pCPU102 are assigned to the virtual machine 300 of VM0
  • pCPU103 and pCPU104 are assigned to the virtual machine 300 of VM1.
  • the GPU 105 it is difficult for the GPU 105 to distinguish between a request for access to the GPU 105 and a response, and during the access to the register, the GPU 105 has an interface of a type that occupies the access source CPU. Physical device is assumed.
  • the hypervisor 200 is provided with a hypervisor scheduler 201, a vGPU driver 202, and the like, as in the first embodiment.
  • the virtual machine 300 includes vCPU 301 and vCPU 302 corresponding to a resident virtual CPU, vCPU 303 corresponding to a non-resident virtual CPU, vGPU 305, vPIC 306, vTIMER 307 corresponding to a virtual device, and the like.
  • a task activation process 308 that activates various tasks and an OS scheduler 309 that performs scheduling of the activated tasks are implemented.
  • a graphic driver 410 as a virtual driver is mounted on the virtual machine 300.
  • the graphic driver 410 of this embodiment is configured to be able to call an access part (s) for processing access to the vGPU 305 performed by the system call unit 311 as a dedicated task TS by the dedicated task request processing 411.
  • cpumaskvS is set so that it can be operated only by the vCPU 303.
  • the graphic driver 410 is called and the system call unit 311 operates. Then, the system call unit 311 requests the access part (s) of the dedicated task TS to start processing by the dedicated task request processing 411, and waits for completion of the processing of the access part (s). At this point, the vCPU 301 enters the waiting state, so that other tasks can be operated on the vCPU 301. That is, if the vCPU 303 enters a waiting state during the execution of the dedicated task TS, the vCPU 301 can be operated.
  • the dedicated task TS is started by the vCPU 303 according to the setting of cpumaskvS.
  • the number of the virtual CPUs to which the physical CPUs are allocated is three, so the hypervisor scheduler 201 tries to distribute the pCPU 101 and the pCPU 102 equally to the three virtual CPUs.
  • the access part (s) of the dedicated task TS starts the processing and accesses the vGPU driver 202, and temporarily waits for the exclusion of another virtual machine 300 to temporarily execute the processing. It waits and resumes processing when the exclusion wait is released.
  • the vCPU 303 goes into a standby state because the processing has been completed, and the dedicated task request processing 411 notified of completion resumes the operation, and the system call unit 311 executes the processing in the first embodiment. Similarly to the case described above, the operation of the vGPU 305 is waited for until the interrupt handler unit 312 operates.
  • the access part (s) is called from the graphic driver 410 as a dedicated task, so that an access request, that is, the start of the processing for the access part (s) and the response to the request are started. That is, it is possible to separate the completion of the processing of the access part (s).
  • access to the vGPU 305 can be performed as pseudo I / O, and other tasks can be executed during the I / O wait period.
  • the physical CPU can be effectively used, and in the virtualization environment 1 in which a virtual computer system is built on the hardware 100, the occupied device is Can be prevented from deteriorating when accessing the URL.
  • the resources of the virtualization environment 1 are not wasted and the performance of the virtualization environment 1 is not affected. Is particularly significant when is required. Further, it is not necessary to modify basic parts such as the task activation processing 308 and the OS scheduler 309.
  • driver software for accessing an occupied virtual device includes a system call unit 311 and an interrupt handler unit 312, and processes access to a virtual device performed from the system call unit 311.
  • a virtual driver configured so that the access portion to be called can be called as a dedicated task TS, and executing a dedicated task TS by a non-resident virtual CPU when accessing a dedicated virtual device from a resident virtual CPU. It is possible to access the virtual device as pseudo I / O.
  • the operation of the virtual CPU becomes simpler than in the first embodiment, so that the above-described access method can be easily realized when targeting a device whose access part (s) can be clearly separated. .
  • the access method of the first embodiment may be better for a device whose access part (s) cannot be clearly separated.
  • the same number of non-resident virtual CPUs as the dedicated physical device are mounted so that the access method according to the first embodiment and the access method according to the second embodiment can be selectively used depending on the physical device. It is also possible to adopt a configuration in which a plurality of virtual drivers are mounted.
  • the configuration in which the dedicated task TS is provided on the virtual machine 300 has been described as an example.
  • a configuration in which similar processing is performed on the hypervisor 200 may be employed. More specifically, in the hypervisor scheduler 201 on the hypervisor 200, in addition to the virtual machine 300, a task configured to directly access an occupied physical device is arranged as a scheduling target, and a non-resident virtual CPU is allocated. When there is a request for access from the hypervisor 200, a task arranged on the hypervisor 200 may be used to access an occupied physical device.
  • the vGPU driver 202 on the hypervisor 200 sets the virtual machine 300 until the operation of the physical device is completed as in the second embodiment. It is possible to wait for processing from the side. Therefore, a request for access from the non-resident virtual CPU can be handled as pseudo I / O, and the allocation of the physical CPU to the non-resident virtual CPU can be canceled during the I / O wait period. Other tasks can be performed on the virtual CPU of the type.
  • the maximum waiting time required for accessing the occupied physical device measured by a preliminary test or the like is set in advance, and if the maximum waiting time is longer than a predetermined time, the access processing is set to non-resident type. When the maximum waiting time is shorter than the specified time, the access processing is executed by the resident virtual CPU.
  • the GPU 105 is illustrated as an occupation type physical device.
  • the access method according to the present embodiment is not limited to the GPU 105.
  • the GPU 105 is applied to processing other than image processing in General-purpose computing on graphics processing units.
  • the present invention can be applied to access to an image processing unit (hereinafter, IPU) dedicated to image processing or a device having an interface unique to a vendor.
  • IPU image processing unit
  • each virtual machine 300 is provided with the same number of resident virtual CPUs as the number of assigned physical CPUs, and the same number of non-resident virtual CPUs as the number of target occupied physical devices. Is applied, it is possible to suppress the performance of the virtualization environment 1 from deteriorating.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Hardware Redundancy (AREA)

Abstract

実施形態のアクセス方法は、仮想化環境１において、仮想マシン３００上に、常には物理ＣＰＵ（ｐＣＰＵ１０１、ｐＣＰＵ１０２）が割り当てられている常駐型の仮想ＣＰＵ（ｖＣＰＵ３０１、ｖＣＰＵ３０２）と、常には物理ＣＰＵが割り当てられていない非常駐型の仮想ＣＰＵ（ｖＣＰＵ３０３）とを実装し、常駐型の仮想ＣＰＵから占有型の物理デバイス（ＧＰＵ１０５）に対応する仮想デバイス（ｖＧＰＵ３０５）にアクセスする際、当該仮想デバイスにアクセスする処理を非常駐型の仮想ＣＰＵに代行させる。

Description

仮想化環境におけるデバイスへのアクセス方法 関連出願の相互参照
　本出願は、２０１８年７月３日に出願された日本出願番号２０１８－１２６７９９号に基づくもので、ここにその記載内容を援用する。
　本開示は、仮想的なコンピュータシステムを構築した仮想化環境においてデバイスにアクセスするためのアクセス方法に関する。
　近年、ハードウェア上に仮想的なコンピュータシステムを構築した仮想化環境の採用が進んでいる。このような仮想化環境では、一般的に、１つのハードウェア上でハイパーバイザを動作させ、そのハイパーバイザ上で複数の仮想的なコンピュータシステムを動作させている。これにより、例えば複数の処理を並列して実行することが可能になる等、システムの高集積化や高性能化を実現することができる。以下、仮想的なコンピュータシステムを仮想マシンと称し、ハードウェアが備えるＣＰＵを物理ＣＰＵ、デバイスを物理デバイス、仮想マシン上に仮想化されたＣＰＵを仮想ＣＰＵ、デバイスを仮想デバイスと称する。
　さて、仮想マシンは、ハードウェアが備えるストレージやネットワークインターフェース等の物理デバイスにアクセスしながら動作する。このとき、仮想マシン上では、仮想ＣＰＵが仮想デバイスにアクセスすることによって、物理デバイスにアクセスしている。そのため、複数の仮想マシンが構築されている場合であっても、各仮想マシンは、他の仮想マシンの存在を特段考慮することなく独自に動作することができる。
　ただし、１つの物理デバイスに対して複数の仮想マシンから同時にアクセスすることはできないため、複数の仮想マシンが構築されている場合には、各仮想マシンは、物理デバイスを排他的に利用することになる。その場合、アクセスするタイミングによっては他の仮想マシンからのアクセスの完了を待機する排他待ちが発生することから、排他待ちを効率的よく実現するためにｖｉｒｔｉｏと呼ばれる仮想化技術が存在している。
　ｖｉｒｔｉｏは、ハイパーバイザ上のデバイスドライバが各仮想マシンからのアクセスの要求をキューイングし、物理デバイスへのアクセスが完了するとその要求に対して応答を返す構成となっている。このため、物理デバイスへのアクセスの要求とその要求に対する応答とが切り分けられ、アクセスを要求してから応答が返ってくるまでの期間がいわゆるＩ／Ｏ待ちの状態となることから、アクセス元となった仮想ＣＰＵではＩ／Ｏ待ちの期間に他のタスクを実行することが可能になる。そして、このようなｖｉｒｔｉｏに対しては、例えば特許文献１のように割り込みのオーバーヘッドを改善する等、仮想化環境を効率化するための提案がなされている。
特表２０１７－５１８５８９号公報
　ところで、物理デバイスの中には、アクセスの要求と応答とを切り分けることが困難なデバイスが存在する。例えば、Graphics Processing Unit(以下、ＧＰＵ）は、独自のレジスタをアクセスして複雑な構造を持つ描画要求メモリを伝達する必要があることから、アクセスの要求と応答とを切り分けることが一般的に困難である。そのため、従来では、ＧＰＵにアクセスする場合には、描画要求メモリへのread/write命令をトリガーとする描画の開始から描画が完了するまでの処理を一括で実行するようにしていた。
　しかしながら、アクセスの終了までの処理を一括で実行する場合、アクセス元となる仮想ＣＰＵは、描画が完了するまでＧＰＵのレジスタへのｒｅａｄ／ｗｒｉｔｅ命令を実行中になる。その場合、描画を処理するタスクをＩ／Ｏ待ちの状態にすることができないことから、アクセス元の仮想ＣＰＵは、ＧＰＵからの応答を待っているだけの状態であったとしても、その待ち時間に他のタスクを実行することができなかった。
　このように仮想ＣＰＵが占有された状態になると、他のタスクに切り替えることができなくなり、仮想マシンの処理能力が低下することになるとともに、割り当てた物理ＣＰＵの利用効率も低下してしまう等、仮想化環境全体のパフォーマンスの低下を招いていた。
　本開示の目的は、ハードウェア上に仮想的なコンピュータシステムを構築した仮想化環境において、アクセス元のＣＰＵを占有するタイプのデバイスにアクセスする際のパフォーマンスの低下を抑制することができるアクセス方法を提供することにある。
　上記目的を達成するために、本開示の一態様によるアクセス方法では、仮想マシン上に、常には物理ＣＰＵに割り当てられている常駐型の仮想ＣＰＵと、常には物理ＣＰＵが割り当てられていない非常駐型の仮想ＣＰＵとを実装し、常駐型の仮想ＣＰＵから占有型の物理デバイスに対応する仮想デバイスにアクセスする際、当該仮想デバイスにアクセスする処理を非常駐型の仮想ＣＰＵに代行させる。
　この場合、当初のアクセス元である常駐型の仮想ＣＰＵは、仮想デバイスにアクセスする処理から開放されることから、他の処理を実行することが可能になる。一方、仮想デバイスにアクセスする処理を代行する非常駐型の仮想ＣＰＵは、仮想マシン上においては仮想デバイスに占有された状態になるものの、その状態は、ハイパーバイザから見れば物理デバイスからの応答を待ち合わせて何も動作していないものとして認識される。
　そのため、ハイパーバイザ上では、何も動作していない非常駐型の仮想ＣＰＵへの物理ＣＰＵの割り当てを解除でき、割り当てが解除された物理ＣＰＵを、他の処理を実行することが可能な状態となっている常駐型の仮想ＣＰＵに割り当てることができる。
　これにより、仮想化環境において占有型の物理デバイスにアクセスする際、仮想マシン上では、非常駐型の仮想ＣＰＵによってアクセスする処理を継続したまま、常駐型の仮想ＣＰＵによって他の処理を実行することができる。したがって、アクセス元のＣＰＵを占有する占有型の物理デバイスにアクセスする場合であっても、仮想化環境のパフォーマンスが低下することを抑制できる。
　本開示についての上記目的及びその他の目的、特徴や利点は、添付の図面を参照しながら下記の詳細な記述により、より明確になる。その図面は、
図１は、第１実施形態による仮想化環境の一例を模式的に示す図であり、 図２は、アクセス時の作動と物理ＣＰＵの割り当て状態との一例を模式的に示す図であり、 図３は、第２実施形態による仮想化環境の一例を模式的に示す図である。
　以下、複数の実施形態について図面を参照しながら説明する。また、各実施形態において実質的に共通する構成には同一の符号を付して説明する。
　　　（第１実施形態）
　以下、第１実施形態について、図１および図２を参照しながら説明する。
　図１に示すように、本実施形態の仮想化環境１は、ハードウェア１００、ハードウェア１００上で動作するハイパーバイザ２００、ハイパーバイザ２００上で動作する複数の仮想マシン３００を含んで構成されている。以下、ハードウェア１００が備えるＣＰＵを物理ＣＰＵ、デバイスを物理デバイス、仮想マシン３００上に仮想化されたＣＰＵを仮想ＣＰＵ、デバイスを仮想デバイスと称して説明する。
　ハードウェア１００は、物理ＣＰＵに相当する例えば４つのｐＣＰＵ１０１～ｐＣＰＵ１０４、物理デバイスに相当するＧＰＵ１０５（Graphics Processing Unit）、Programmable Interrupt Controller（以下ＰＩＣ）１０６、およびＴＩＭＥＲ１０７等を備えている。本実施形態の場合、ハードウェア１００上には４つのＣＰＵコアを単一パッケージに収容したＣＰＵが設けられており、これら４つのＣＰＵコアをそれぞれ個別の物理ＣＰＵとして扱っている。また、各物理ＣＰＵは、ｐＣＰＵ１０１およびｐＣＰＵ１０２がＶＭ０の仮想マシン３００に割り当てられ、ｐＣＰＵ１０３およびｐＣＰＵ１０４がＶＭ１の仮想マシン３００に割り当てられている。
　ＧＰＵ１０５は、周知のようにディスプレイ２への描画を処理する機能を有しており、本実施形態では、独自のレジスタに複雑な構造を持つ描画要求メモリを伝達することで描画を処理する。このＧＰＵ１０５は、詳細は後述するが、ＧＰＵ１０５へのアクセスの要求と応答とを切り分けることが困難であり、レジスタへのアクセス中にはアクセス元のＣＰＵを占有するタイプのインターフェースを備えた占有型の物理デバイスに相当する。また、このＧＰＵ１０５は、それぞれの仮想マシン３００によって共有される共有デバイスでもある。
　ＰＩＣ１０６は、ＧＰＵ１０５等の物理デバイスからの割り込みの設定や割り込みの有効化／無効化あるいは割り込みの通知先となるＣＰＵの設定等、ハイパーバイザ２００上で発生する割り込みを制御するための周知の機能を有している。ＴＩＭＥＲ１０７は、ハイパーバイザ２００上で必要となる各種の時間を計時する機能を有しており、例えばタイマ割り込み等の周知の処理に利用される。なお、図示は省略するが、ハードウェア１００上には、例えばembedded Multi Media Card（以下、ｅＭＭＣ）等のストレージデバイスやNetwork Interface Card（以下、ＮＩＣ）のような通信デバイス等の物理デバイス等も設けられている。
　ハイパーバイザ２００は、周知のようにハードウェア１００を仮想化することによって例えば複数の仮想マシン３００を動作させるソフトウェアである。本実施形態では、ハードウェア１００上でハイパーバイザ２００が直接動作し、そのハイパーバイザ２００上で仮想マシン３００が動作するベアメタル型あるいはネイティブ型と称されるものを想定している。このハイパーバイザ２００には、ハイパーバイザスケジューラ２０１、ｖＧＰＵドライバ２０２等が設けられている。
　ハイパーバイザスケジューラ２０１は、各仮想マシン３００のスケジューリング等を行うソフトウェアである。ｖＧＰＵドライバ２０２は、仮想マシン３００上に仮想デバイスを実現するためのドライバソフトウェアであり、本実施形態ではＧＰＵ１０５を仮想化した仮想デバイスであるｖＧＰＵ３０５を仮想マシン３００上に実現している。
　ｖＧＰＵドライバ２０２は、各仮想マシン３００からのアクセスを排他的に処理する排他ロック機能２０３を有している。なお、図１では、排他ロック機能２０３をｌｏｃｋとして示している。ｖＧＰＵドライバ２０２は、各仮想マシン３００から物理デバイスへのアクセスが要求された場合、排他ロック機能２０３により各仮想マシン３００からのアクセスを排他的に処理することで、それぞれの仮想マシン３００からのアクセスの要求に対して正しく物理デバイスを利用できるように制御する。なお、図１では図示を省略しているが、ハイパーバイザ２００には他のアプリケーションや他の物理デバイス用のドライバソフトウェア等も実装されている。
　仮想マシン３００は、周知のようにハイパーバイザ２００上で動作する仮想的なコンピュータシステムであり、仮想ＣＰＵ上で仮想Operating System（以下、仮想ＯＳ）を動作させ、仮想デバイスにアクセスしながら各種の処理を実行するように構成されている。本実施形態では、ハイパーバイザ２００上に構築されているＶＭ０およびＶＭ１の２つの仮想マシン３００は同一構成となっている。そのため、以下では主としてＶＭ０の仮想マシン３００を例にして説明する。なお、異なる構成の仮想マシン３００を構築することも可能である。
　仮想マシン３００は、仮想ＣＰＵに相当するｖＣＰＵ３０１、ｖＣＰＵ３０２およびｖＣＰＵ３０３、仮想デバイスに相当するｖＧＰＵ３０５、ｖＰＩＣ３０６、ｖＴＩＭＥＲ３０７等を備えている。このうち、ｖＣＰＵ３０１およびｖＣＰＵ３０２は、常には物理ＣＰＵに割り当てられて動作可能になっている常駐型の仮想ＣＰＵに相当し、ｖＣＰＵ３０３は、常には物理ＣＰＵに割り当てられておらず、必要に応じて物理ＣＰＵが割り当てられて動作可能になる非常駐型の仮想ＣＰＵに相当する。つまり、仮想マシン３００は、常には動作可能な仮想ＣＰＵが、割り当てられる物理ＣＰＵの数だけ実装されている。
　各仮想ＣＰＵには、割り当て可能な物理ＣＰＵを示すｃｐｕｍａｓｋがそれぞれ設定されている。このｃｐｕｍａｓｋには、割り当てが可能な物理ＣＰＵの識別情報が例えばビット列として設定されている。例えばＶＭ０の場合、ｖＣＰＵ３０１、ｖＣＰＵ３０２およびｖＣＰＵ３０３の３つの仮想ＣＰＵには、それぞれｐＣＰＵ１０１およびｐＣＰＵ１０２の２つの物理ＣＰＵが割り当て可能であることを示す値が設定されている。なお、ＶＭ１の場合、３つの仮想ＣＰＵのｃｐｕｍａｓｋには、ｐＣＰＵ１０３とｐＣＰＵ１０４の２つの物理ＣＰＵが割り当て可能であることを示す値が設定される。つまり、各仮想マシン３００上の各仮想ＣＰＵには、それぞれ物理ＣＰＵが重複しないように割り当てられている。
　これにより、各仮想マシン３００の仮想ＣＰＵに対して物理ＣＰＵが個別に配分され、互いの仮想マシン３００の動作が他方の仮想マシン３００のパフォーマンスに影響を与えるおそれを無くすことができる。なお、ｃｐｕｍａｓｋは割り当て可能な物理ＣＰＵを識別する値であって、実際にどの物理ＣＰＵが割り当てられるかは、ハイパーバイザスケジューラ２０１によって管理される。
　仮想マシン３００上には、周知のように、各種のタスクＴ０～ＴＮを起動するタスク起動処理３０８、起動されたタスクのスケジューリング等を行うＯＳスケジューラ３０９が実装されている。また、仮想マシン３００上には、仮想デバイスにアクセスするためのドライバソフトウェアである仮想ドライバが実装されている。本実施形態では、ｖＧＰＵ３０５にアクセスするためのグラフィックドライバ３１０を想定している。なお、図１では図示を省略しているが、他の仮想デバイス用のドライバソフトウェアも実装されている。
　各タスクには、タスク起動処理３０８によってｃｐｕｍａｓｋｖが設定される。このｃｐｕｍａｓｋｖは、そのタスクを実行可能な仮想ＣＰＵの番号等の識別情報が設定されている。本実施形態の場合、各タスクのｃｐｕｍａｓｋｖには、常駐型の仮想ＣＰＵであるｖＣＰＵ３０１およびｖＣＰＵ３０２での実行を許可する一方、非常駐型の仮想ＣＰＵであるｖＣＰＵ３０３での実行を許可しない値が設定される。そのため、起動したタスクは、ｃｐｕｍａｓｋｖを参照したＯＳスケジューラ３０９によって、ｖＣＰＵ３０１またはｖＣＰＵ３０２のいずれかに割り振られる。このとき、ＯＳスケジューラ３０９は、各仮想ＣＰＵが均等に使用されるようにタスクを割り振る。
　グラフィックドライバ３１０は、占有型の仮想デバイスであるｖＧＰＵ３０５にアクセスするためのものであり、仮想デバイスにアクセスするアクセス部分（ｓ）を有するシステムコール部３１１と、アクセス部分（ｉ）を有する割り込みハンドラ部３１２とを含んでいる。なお、システムコール部３１１および割り込みハンドラ部３１２の動作は周知であるので、説明を省略する。
　また、グラフィックドライバ３１０は、ｃｐｕｍａｓｋ変更処理３１３、および、ＩＲＱｍａｓｋ設定処理３１４を有している。詳細は後述するが、ｃｐｕｍａｓｋ変更処理３１３は、詳細は後述するがタスクに設定されているｃｐｕｍａｓｋを変更する処理であり、ＩＲＱｍａｓｋ設定処理３１４は、割り込みハンドラ部３１２を動作させる仮想ＣＰＵを示すＩＲＱｍａｓｋ３１５を設定する処理である。ｖＧＰＵ３０５の場合、仮想マシン３００の起動時に、ＩＲＱｍａｓｋ設定処理３１４によって割り込みハンドラ部３１２がｖＣＰＵ３０３でのみ動作するように設定されている。
　次に、上記した構成の作用について説明する。
　まず、ハイパーバイザ２００を採用した仮想化環境１の動作について簡単に説明する。ハイパーバイザ２００は、ハイパーバイザスケジューラ２０１、物理ＣＰＵ、ＰＩＣ１０６やＴＩＭＥＲ１０７等を利用しつつ仮想マシン３００を並列動作させている。このとき、各仮想マシン３００のリアルタイム性能を最大限に活かすため、ｃｐｕｍａｓｋを設定して物理ＣＰＵをそれぞれの仮想マシン３００に対して個別に配分し、他の仮想マシン３００の影響を受けないように、また、他の仮想マシン３００に影響を与えないようにしている。
　具体的には、例えばｖＣＰＵ３０１とｖＣＰＵ３０２が稼動状態となっており、ｖＣＰＵ３０３が待機状態となっている場合には、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１とｖＣＰＵ３０２のｃｐｕｍａｓｋを参照して、例えばｐＣＰＵ１０１をｖＣＰＵ３０１に割り当て、ｐＣＰＵ１０２をｖＣＰＵ３０２に割り当てる。なお、ここで言う稼動状態とは、仮想ＣＰＵに何らかの処理が割り振られた状態を意味しており、稼動状態の仮想ＣＰＵに物理ＣＰＵが割り当てられると、その仮想ＣＰＵは動作可能な状態になる。
　一方、ハイパーバイザ２００は、ｖＣＰＵ３０３が稼動状態になると、ｐＣＰＵ１０１またはｐＣＰＵ１０２をｖＣＰＵ３０３に割り当て、その期間はｖＣＰＵ３０１かｖＣＰＵ３０２のいずれかは物理ＣＰＵ待ちの状態になる。このように、ハイパーバイザ２００は、仮想ＣＰＵに対して極力均等に物理ＣＰＵが割り当てることで、仮想化環境１が効率的に動作するようにしている。これにより、各仮想マシン３００は、２つの物理ＣＰＵを備えたＯＳと同等の性能で動作することができ、複数のタスクの同時実行がハイパーバイザ２００を使わない通常のＯＳと同様に実現されている。
　さて、このような仮想化環境１では、各仮想マシン３００は、ハードウェア１００上のＧＰＵ１０５や上記したｅＭＭＣあるいはＮＩＣ等の物理デバイスを共有してアクセスすることがある。そのため、仮想化環境１では、例えばｖＧＰＵドライバ２０２をハイパーバイザ２００上で動作させ、仮想マシン３００上に仮想デバイスを実現することにより、各仮想マシン３００では独立したデバイスのようにアクセスすることを可能としている。
　ただし、ハードウェア１００が備える物理デバイスが１つの場合には、複数の仮想マシン３００からのアクセスの要求は時分割で排他的に処理されることになる。その場合、他の仮想マシン３００がアクセスしている場合には排他待ち状態となることから、前述したｖｉｒｔｉｏのような仮想化技術が存在している。
　ただし、物理デバイスの中には、本実施形態のＧＰＵ１０５のようにアクセスの要求と応答とを切り分けることが困難であり、また、アクセス時にレジスタ命令の実行中となってタスクをＩ／Ｏ待ちの状態にすることができないような占有型のデバイスが存在する。このような占有型のデバイスにアクセスする場合には、例えばＧＰＵ１０５からの応答を待っているだけの状態であったとしても、その待ち時間に他のタスクを実行することができないことから、仮想化環境１のパフォーマンスが低下することになる。
　具体的には、ＧＰＵ１０５で言えば描画実行中には描画以外のタスクを実行できず、ＣＰＵの有効活用ができないことから、他処理の遅延を招いてしまうことになる。特に、描画処理では大量の仮想マシン３００上のメモリにアクセスすることから、その待ち時間が例えば数十ミリ秒かかってしまうようなケースも想定される。その場合、他のタスクが実行できなくなると、画像とともに音声再生のタスクを同時実行している場合には、音切れを発生させてしまう。また、リアルタイム性を求める処理が実行されない場合や遅延する場合も想定される。
　そこで、本実施形態では、占有型のデバイスへのアクセス中には仮想ＣＰＵが占有されて他のタスクへの切り替えはできないものの、物理ＣＰＵは何も処理をしていない状態になっていることに着目し、仮想化環境１のパフォーマンスが低下することを抑制している。
　以下、仮想マシン３００上で起動されたタスクＴ０からＧＰＵ１０５に対するアクセスの要求が発行される場合を例にして、本実施形態のアクセス方法について説明する。なお、一般的なＯＳの場合にはアプリケーションはプロセス空間を有するものでありスレッドと称されることもあるが、本明細書では、アプリケーションであってもＯＳ内部で実行されるものであっても、同時に実行可能なプログラム単位をタスクと称している。
　さて、仮想マシン３００上でタスクＴ０が起動されると、タスクＴ０は、ｃｐｕｍａｓｋｖの設定によりｖＣＰＵ３０１またはｖＣＰＵ３０２に割り当てられる。ここでは、図２に示すように、例えば時刻ｔ０においてタスクＴ０が起動され、タスクＴ０がｖＣＰＵ３０１に割り当てられたとする。なお、図２の物理ＣＰＵの割り当て状態として示すように、タスクＴ０を実行するｖＣＰＵ３０１には物理ＣＰＵとしてｐＣＰＵ１０１が割り当てられているものとする。また、図２において各タスクに対応して設けた太線は、物理ＣＰＵが割り当てられていることを示している。
　タスクＴ０が実行されてグラフィックドライバ３１０を呼び出されると、タスクＴ０ではシステムコール部３１１が動作する。システムコール部３１１では、まず、タスクＴ０のｃｐｕｍａｓｋｖ０をｖＣＰＵ３０３でのみ実行可能となるように変更するｃｐｕｍａｓｋ変更処理３１３が実行される。また、このｃｐｕｍａｓｋ変更処理３１３では、ｃｐｕｍａｓｋｖ０がｖＣＰＵ３０１およびｖＣＰＵ３０２を含まない値に変更されたことを確認すると、タスクＴ０を実行可能になったｖＣＰＵ３０３にタスクＴ０を再割り当てするようにＯＳスケジューラ３０９に指示が出される。
　ＯＳスケジューラ３０９に指示が出されると、ｖＣＰＵ３０３が他のタスクに使用されている場合には一旦待ち状態となるが、ｖＣＰＵ３０３が使われていなかった場合あるいは待ち状態が終了した場合には、ｖＣＰＵ３０３にタスクＴ０が割り当られてｖＣＰＵ３０３が稼動状態になる。仮想ＣＰＵの稼動状態はハイパーバイザ２００上のハイパーバイザスケジューラ２０１によってチェックされていることから、ｖＣＰＵ３０３が稼動状態になったこともハイパーバイザスケジューラ２０１に検知されることになる。
　ｖＣＰＵ３０３が稼動状態になったことを検知したハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１およびｖＣＰＵ３０２に加えて、ｖＣＰＵ３０３を物理ＣＰＵの割り当て対象とする。この状態では一時的には３つの仮想ＣＰＵが２つの物理ＣＰＵ上で動作することになるため、例えば図２の時刻ｔ１においてｖＣＰＵ３０３にｐＣＰＵ１０１が割り当てられたとすると、それまでｐＣＰＵ１０１が割り当てられていたｖＣＰＵ３０１は一時的に物理ＣＰＵ待ちの状態になる。つまり、時刻ｔ１において、タスクＴ０を実行する仮想ＣＰＵが、ｖＣＰＵ３０１からｖＣＰＵ３０３に切り替えられる。
　この時点でシステムコール部３１１がｖＣＰＵ３０３で動作可能な状態になることから、システムコール部３１１の処理をｖＣＰＵ３０３上で継続することができる。そのため、システムコール部３１１は、アクセス部分（ｓ）を呼び出し、アクセス部分（ｓ）はｖＧＰＵ３０５のレジスタにアクセスする。ｖＧＰＵ３０５へのアクセスはハイパーバイザ２００上のｖＧＰＵドライバ２０２に伝達されるものの、他の仮想マシン３００の実行の待ち合わせやＧＰＵ１０５へアクセスする準備のために排他ロック機能２０３によって一旦待機する。このとき、ｖＣＰＵ３０３は、ロック解除待ちで待機状態になる。
　例えば図２の時刻ｔ２においてｖＣＰＵ３０３が待機状態になったとすると、処理が仮想マシン３００からハイパーバイザ２００に移管されるＶＭホスト切り替えが行われる。このとき、ハイパーバイザスケジューラ２０１は、待機状態になって何も処理を行っていないｖＣＰＵ３０３へのｐＣＰＵ１０１の割り当てを解除するとともに、物理ＣＰＵ待ちの状態となっているｖＣＰＵ３０１にｐＣＰＵ１０１を再び割り当ててｖＣＰＵ３０１を動作可能な状態とする。ｖＣＰＵ３０１が動作可能な状態になると、仮想マシン３００上では例えばタスクＴ１をｖＣＰＵ３０１で実行することが可能になる。
　そのため、３つの仮想ＣＰＵに２つの物理ＣＰＵを割り当てている状態であっても、ｖＣＰＵ３０３は待機状態となっていることから物理ＣＰＵの割り当てを解除でき、その結果、実質的にｖＣＰＵ３０１とｖＣＰＵ３０２の２つの仮想ＣＰＵで２つの物理ＣＰＵを占有的に使用することが可能になる。このため、仮にアクセス部分（s）のレジスタへのアクセスが遅延したりアクセスに時間を要したりする場合であっても、仮想化環境１全体としての性能は実質的に２つの仮想ＣＰＵに２つの物理ＣＰＵを割り当てた状態と同等となり、仮想化環境１のパフォーマンスを維持することが可能になる。
　さて、ｖＧＰＵドライバ２０２にて排他待ちのロックが解除されてＧＰＵ１０５へのアクセスが終了すると、その結果がアクセス部分（ｓ）に返されることから、タスクＴ０が動作可能な状態、より具体的に言えば、中断していたアクセス部分（ｓ）が動作を再開可能な状態になる。この場合、ｖＣＰＵ３０３に物理ＣＰＵを割り当てる必要があるが、タスクＴ０が動作可能な状態になったことを検知したハイパーバイザスケジューラ２０１により所定のスケジューリング時間後に物理ＣＰＵの割り当てが見直され、ｖＣＰＵ３０３に例えばｐＣＰＵ１０１が割り当てられる。これにより、アクセス部分（ｓ）は動作を再開する。
　そして、アクセス部分（ｓ）の処理が終わると、ｃｐｕｍａｓｋ変更処理３１３によって、ｃｐｕｍａｓｋｖ０を、ｖＣＰＵ３０１およびｖＣＰＵ３０２での実行を許可する一方、ｖＣＰＵ３０３での実行を許可しない値に変更する。つまり、ｃｐｕｍａｓｋｖ０は元の値に戻される。その結果、タスクＴ０がｖＣＰＵ３０１またはｖＣＰＵ３０２の動作待ちになるとともに、ｖＣＰＵ３０３が何も処理をしていない状態になる。
　そのため、ハイパーバイザスケジューラ２０１は、何も処理をしていないｖＣＰＵ３０３を物理ＣＰＵの割り当てを解除し、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵを割り当てるように動作する。これにより、ｖＣＰＵ３０１とｖＣＰＵ３０２は、それぞれｐＣＰＵ１０１とｐＣＰＵ１０２をフルタイムで利用可能な状態に復帰する。
　ここで注目すべきは、レジスタへのアクセス中は、タスクＴ０としては待機状態ではなくｖＣＰＵ３０３上で動作状態であったことである。ＯＳスケジューラ３０９は、動作状態にあるタスクから他のタスクに切り替えることができないため、従来であれば、タスクＴ０を実行していたｖＣＰＵ３０１に他のタスクを実行させることができなかった。
　これに対して、本実施形態では、ｃｐｕｍａｓｋ変更処理３１３によってタスクＴ０の実行主体をｖＣＰＵ３０１からｖＣＰＵ３０３に切り替えている。つまり、ｖＧＰＵ３０５にアクセスする処理をｖＣＰＵ３０３に代行させている。この状態では３つの仮想ＣＰＵが動作することになるものの、実質的にはｖＧＰＵドライバ２０２は排他待ちの状態になっていることから、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０３には物理ＣＰＵを割り当てず、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵが割り当てている。
　つまり、非常駐型の仮想ＣＰＵであるｖＣＰＵ３０３を設けて、ｖＣＰＵ３０３がｖＧＰＵ３０５の動作完了を待ち合わせて待機状態となるように構成したことにより、ｖＣＰＵ３０１をタスクＴ０から開放することが可能となり、ｖＣＰＵ３０１に他のタスクを実行させることができ、仮想化環境１全体として効率的な動作が可能になったのである。
　ところで、グラフィックドライバ３１０のシステムコール部３１１は、ｖＧＰＵ３０５のレジスタへのアクセスだけでシステムコールの目的を果たすものもあれば、ｖＧＰＵ３０５の状態の変化を待ち合わせてからレジスタアクセスをする場合もある。この場合、システムコール部３１１は要求内容をメモリ上に記録し、ｖＧＰＵ３０５の状態変化があったときに動作するように設定して終了する。
　ｖＧＰＵ３０５の状態変化は、割り込みによって通知される。このとき、ＰＩＣ１０６によってハイパーバイザスケジューラ２０１に割り込みが通知される。通知された割り込みは、ｖＰＩＣ３０６のＩＲＱｍａｓｋ３１５によってｖＣＰＵ３０３が設定されていることから、ｖＣＰＵ３０３で処理されることになる。そのため、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０３の割り込みハンドラ部３１２を動作させるために、ｖＣＰＵ３０３に物理ＣＰＵを割り当てる。
　割り込みハンドラ部３１２が動作してアクセス部分（ｉ）がｖＧＰＵ３０５のレジスタにアクセスすると、ｖＧＰＵ３０５へのアクセスはハイパーバイザ２００上のｖＧＰＵドライバ２０２に伝達されるものの、他の仮想マシン３００の実行の待ち合わせやＧＰＵ１０５へアクセスする準備のために排他ロック機能２０３によって一旦待機する。このとき、ｖＣＰＵ３０３は、ロック解除待ちで待機状態になる。このとき、ハイパーバイザスケジューラ２０１は、アクセス部分（ｓ）と同様に、排他待ち状態となったｖＣＰＵ３０３への物理ＣＰＵの割り当てを解除するとともに、ｖＣＰＵ３０１とｖＣＰＵ３０２に物理ＣＰＵを割り当てて動作させる。これにより、アクセス部（ｉ）のレジスタへのアクセス待ちの間も仮想マシン３００上の他のタスクを動作可能にすることができるようになる。
　そして、ｖＧＰＵドライバ２０２の排他待ちが完了すると、アクセス部分（ｉ）が動作を再開し、ｖＧＰＵドライバ２０２を経由してＧＰＵ１０５のアクセスが可能となる。また、割り込みハンドラ部３１２の動作が終了すると、ｖＣＰＵ３０３が空きとなり、ハイパーバイザスケジューラ２０１は、ｖＣＰＵ３０１とｖＣＰＵ３０２の処理だけを行うようになる。
　このように、本実施形態では、グラフィックドライバ３１０において、アクセス部分（ｓ）およびアクセス部分（ｉ）の処理を非常駐型のｖＣＰＵ３０３で行うことにより、レジスタへのアクセスを待ち合わせてアクセス元のＣＰＵが占有されるような場合であっても、他のタスクが常駐型の仮想ＣＰＵで動作できるアクセス方法を採用している。
　以上説明したアクセス方法によれば、次のような効果を得ることができる。
　アクセス方法は、仮想化環境１において、仮想マシン３００上に、常には物理ＣＰＵが割り当てられている常駐型の仮想ＣＰＵ（ｖＣＰＵ３０１、ｖＣＰＵ３０２）と、常には物理ＣＰＵが割り当てられていない非常駐型の仮想ＣＰＵ（ｖＣＰＵ３０３）とを実装し、常駐型の仮想ＣＰＵから占有型の物理デバイスに対応する仮想デバイスにアクセスする際、当該仮想デバイスにアクセスする処理を非常駐型の仮想ＣＰＵに代行させる。
　これにより、アクセス元となる常駐型の仮想ＣＰＵから非常駐型の仮想ＣＰＵに処理が移管され、非常駐型の仮想ＣＰＵがアクセス中に占有状態になったとしても、常駐型の仮想ＣＰＵにおいて他のタスクを実行することが可能になる。この場合、アクセス中に占有状態になった非常駐型の仮想ＣＰＵが実質的に何も処理をしていない待機状態になれば物理ＣＰＵの割り当てを解除できるため、占有型のデバイスへのタスクを継続したまま、常駐型の仮想ＣＰＵに物理ＣＰＵを割り当てて他のタスクを実行させることができる。
　したがって、占有型の物理デバイスにアクセスする場合であっても物理ＣＰＵを有効的に利用することができ、ハードウェア１００上に仮想的なコンピュータシステムを構築した仮想化環境１において、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。
　また、システムコール要求におけるレジスタアクセスは、システムコール呼び出しの延長時に行うものと、割り込みの延長時に行うものとの２つが想定されるものの、いずれの場合にも上記したアクセス方法を適用でき、占有型のデバイスへのアクセス時に物理ＣＰＵを有効活用することができる。
　この場合、非常駐型の仮想ＣＰＵは稼動状態でなければ物理ＣＰＵの割り当て対象とはならないため、単純に３つの常駐型の仮想ＣＰＵを設けて時系列で３つの仮想ＣＰＵをスケジューリングする構成とは異なり、仮想化環境１のパフォーマンスに影響を与えることもない。したがって、仮想化環境１にリアルタイム性が求められる場合において、特に有意となる。
　この場合、本実施形態のように、占有型の仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部３１１と割り込みハンドラ部３１２とを含み、前記システムコール部３１１と前記割り込みハンドラ部３１２のそれぞれに仮想デバイスにアクセスするアクセス部分が設けられている仮想ドライバを実装し、常駐型の仮想ＣＰＵから占有型の仮想デバイスにアクセスする際、少なくともアクセス部分（ｓ、ｉ）を非常駐型の仮想ＣＰＵで代行するアクセス方法を採用することができる。
　このような構成によっても、アクセス部分（ｓ）を切り分けて処理することが難しいデバイスであっても占有型のデバイスへのアクセスを非常駐型の仮想ＣＰＵに容易に代行させることが可能となり、上記したように占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。
　また、本実施形態のように、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させる場合であっても、それぞれの仮想マシン３００において上記したアクセス方法を採用することにより、各仮想マシン３００の性能を維持することができる。つまり、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させ、複数の仮想マシン３００に物理ＣＰＵを重複しないように割り当てる構成とすることで、より厳密には、各仮想マシン３００上の各仮想ＣＰＵにそれぞれ物理ＣＰＵを重複しないように割り当てることで、仮想化環境１の性能が最も高くなると期待できる。
　また、本実施形態ではハードウェア１００が１つの占有型の物理デバイスを備える構成を例示したが、ハードウェア１００が複数の占有型の物理デバイスを備えている場合には、ハードウェア１００が備える占有型の物理デバイスと同じ数の非常駐型の仮想ＣＰＵを実装することにより、上記したアクセス方法を採用することができる。
　換言すると、仮想マシン３００に割り当てられる物理ＣＰＵの数に等しい常駐型の仮想ＣＰＵと、仮想マシン３００においてアクセス対象となる占有型の物理デバイスの数に等しい非常駐型の仮想ＣＰＵとを設けることにより、占有型の物理デバイスにアクセスするとき以外の期間においては従来と同等の性能を確保することができるとともに、占有型の物理デバイスにアクセスする期間においては従来では不可能であった別のタスクの実行が可能となり、仮想化環境１の性能を向上させることができる。
　ただし、常駐型の仮想ＣＰＵは、必要とされる場合には、仮想マシン３００に割り当てられる物理ＣＰＵの数よりも多くすることもできる。そのような構成であっても、非常駐型の仮想ＣＰＵを別途設けることにより、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。
　　　（第２実施形態）
　以下、第２実施形態について、図３を参照しながら説明する。第２実施形態では、システムコール部３１１で動作するアクセス部分（ｓ）を専用タスクとしている点において第１実施形態と異なっている。
　図３に示すように、本実施形態の仮想化環境１は、ハードウェア１００、ハードウェア１００上で動作するハイパーバイザ２００、ハイパーバイザ２００上で動作する複数の仮想マシン３００を含んで構成されており、そのハードウェア１００上でハイパーバイザ２００が動作するとともに、そのハイパーバイザ２００上でＶＭ０およびＶＭ１の２つの仮想マシン３００が動作している。
　ハードウェア１００は、第１実施形態と同様に、物理ＣＰＵに相当する４つのｐＣＰＵ１０１～ｐＣＰＵ１０４、物理デバイスに相当するＧＰＵ１０５、ＰＩＣ１０６、およびＴＩＭＥＲ１０７等を備えている。このうち、ｐＣＰＵ１０１およびｐＣＰＵ１０２は、ＶＭ０の仮想マシン３００に割り当てられ、ｐＣＰＵ１０３およびｐＣＰＵ１０４は、ＶＭ１の仮想マシン３００に割り当てられている。
　ＧＰＵ１０５は、第１実施形態と同様に、ＧＰＵ１０５へのアクセスの要求と応答とを切り分けることが困難であり、レジスタへのアクセス中にはアクセス元のＣＰＵを占有するタイプのインターフェースを備えた占有型の物理デバイスを想定している。
　ハイパーバイザ２００は、第１実施形態と同様に、ハイパーバイザスケジューラ２０１、ｖＧＰＵドライバ２０２等が設けられている。仮想マシン３００は、第１実施形態と同様に、常駐型の仮想ＣＰＵに相当するｖＣＰＵ３０１およびｖＣＰＵ３０２、非常駐型の仮想ＣＰＵに相当するｖＣＰＵ３０３、仮想デバイスに相当するｖＧＰＵ３０５、ｖＰＩＣ３０６、ｖＴＩＭＥＲ３０７等を備えているとともに、各種のタスクを起動するタスク起動処理３０８、起動されたタスクのスケジューリング等を行うＯＳスケジューラ３０９が実装されている。
　また、仮想マシン３００上には、仮想ドライバとしてのグラフィックドライバ４１０が実装されている。本実施形態のグラフィックドライバ４１０は、専用タスク要求処理４１１により、システムコール部３１１から行われるｖＧＰＵ３０５へのアクセスを処理するアクセス部分（ｓ）を専用タスクＴＳとして呼び出し可能に構成されている。この専用タスクＴＳは、ｖＣＰＵ３０３でのみ動作が可能となるようにｃｐｕｍａｓｋｖＳが設定されている。
　さて、仮想マシン３００上で起動したタスクＴ０からｖＧＰＵ３０５へのアクセスが発生すると、グラフィックドライバ４１０が呼び出されてシステムコール部３１１が動作する。すると、システムコール部３１１は、専用タスク要求処理４１１によって専用タスクＴＳのアクセス部分（ｓ）に処理の開始を要求するとともに、アクセス部分（ｓ）の処理の完了を待ち合わせる。この時点でｖＣＰＵ３０１は待ち状態となることから、他のタスクをｖＣＰＵ３０１上で動作させることが可能になる。つまり、専用タスクＴＳの実行中にｖＣＰＵ３０３が待ち状態になれば、ｖＣＰＵ３０１を動作させることができる。
　この専用タスクＴＳは、ｃｐｕｍａｓｋｖＳの設定によってｖＣＰＵ３０３で処理を開始する。この状態では物理ＣＰＵを割り当てる仮想ＣＰＵが３つになるため、ハイパーバイザスケジューラ２０１は、ｐＣＰＵ１０１とｐＣＰＵ１０２を３つの仮想ＣＰＵに均等に配分しようとする。そして、ｖＣＰＵ３０３に物理ＣＰＵが割り当てられると、専用タスクＴＳのアクセス部分（ｓ）は、処理を開始してｖＧＰＵドライバ２０２をアクセスし、他の仮想マシン３００の排他待ちであれば一時的に処理を待機し、排他待ちが解除されると処理を再開する。
　アクセス部分（ｓ）の処理が完了すると、ｖＣＰＵ３０３は、処理がなくなって待機状態となるとともに、完了が通知された専用タスク要求処理４１１が動作を再開し、システムコール部３１１は、第１実施形態と同様に割り込みハンドラ部３１２が動作するまでｖＧＰＵ３０５の動作完了待ちの状態となる。
　このように、本実施形態では、アクセス部分（ｓ）を専用タスクとしてグラフィックドライバ４１０から呼び出す構成としたことにより、アクセスの要求つまりはアクセス部分（ｓ）への処理の開始と、その要求に対する応答つまりはアクセス部分（ｓ）の処理の完了とを切り離すことが可能になる。これにより、ｖＧＰＵ３０５へのアクセスを言わば擬似的なＩ／Ｏとして行うことが可能となり、そのＩ／Ｏ待ちの期間に他のタスクを実行することが可能になる。
　したがって、占有型の物理デバイスにアクセスする場合であっても物理ＣＰＵを有効的に利用することができ、ハードウェア１００上に仮想的なコンピュータシステムを構築した仮想化環境１において、占有型のデバイスにアクセスする際のパフォーマンスの低下を抑制することができる。
　この場合、第１実施形態と同様に、仮想化環境１のリソースを無駄に減らすことがなく、また、仮想化環境１のパフォーマンスに影響を与えることもないことから、仮想化環境１にリアルタイム性が求められる場合において特に有意となる。また、タスク起動処理３０８やＯＳスケジューラ３０９等の基本的な部分に手を加える必要もない。
　また。本実施形態のように、占有型の仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部３１１と割り込みハンドラ部３１２とを含み、システムコール部３１１から行われる仮想デバイスへのアクセスを処理するアクセス部分を、専用タスクＴＳとして呼び出し可能に構成した仮想ドライバを実装し、常駐型の仮想ＣＰＵから占有型の仮想デバイスにアクセスする際、専用タスクＴＳを非常駐型の仮想ＣＰＵで実行することにより、仮想デバイスへのアクセスを擬似的なＩ／Ｏとして行うことが可能となる。
　これにより、仮想ＣＰＵの動作が第１実施形態よりもシンプルなものになるため、アクセス部分（ｓ）を明確に分離できるデバイスを対象とする場合に容易に上記したアクセス方法を実現することができる。
　ただし、アクセス部分（ｓ）が明確に分離できないデバイスを対象とする場合には第１実施形態のアクセス方法の方がよい場合もあるため、例えば対象となる占有型の物理デバイスが複数存在する場合には、物理デバイスによって第１実施形態のアクセス方法と第２実施形態のアクセス方法とを使い分けできるように、占有型の物理デバイスと同じ数の非常駐型の仮想ＣＰＵを実装するとともに、それぞれに適した複数の仮想ドライバを実装する構成とすることもできる。
　　　（その他の実施形態）
　第２実施形態では、仮想マシン３００上に専用タスクＴＳを設ける構成を例示したが、ハイパーバイザ２００上で類似の処理は行う構成とすることもできる。具体的には、ハイパーバイザ２００上のハイパーバイザスケジューラ２０１に、仮想マシン３００に加えて、占有型の物理デバイスに直接的にアクセス可能に構成したタスクをスケジューリング対象として配置し、非常駐型の仮想ＣＰＵからアクセスの要求があった際、ハイパーバイザ２００上に配置したタスクを用いて占有型の物理デバイスにアクセスする構成とすることができる。
　このような構成の場合、ハイパーバイザ２００上のｖＧＰＵドライバ２０２は、タスクが物理デバイスへのアクセスを処理しているとき、第２実施形態のように、物理デバイスの動作が完了するまで仮想マシン３００側からの処理を待ち合わせることが可能になる。そのため、非常駐型の仮想ＣＰＵからのアクセスの要求を擬似的なＩ／Ｏとして扱うことができ、Ｉ／Ｏ待ちの期間には非常駐型の仮想ＣＰＵへの物理ＣＰＵの割り当てを解除できることから、常駐型の仮想ＣＰＵにおいて他のタスクを実行することができる。
　これにより、デバイスにアクセスする際のパフォーマンスの低下を抑制することができる、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させる場合であっても各仮想マシン３００の性能を維持することができる等、各実施形態と同様の効果を得ることができる。また、タスクをハイパーバイザスケジューラ２０１上に配置していることから、仮想マシン３００上のＯＳスケジューラ３０９を介さずにその動作をスケジューリングすることができるため、例えばリアルタイム性が求められるアプリケーションに適用する等、優先度が高い処理に好適なものとなる。
　各実施形態では占有型の物理デバイスへのアクセスを非常駐型の仮想ＣＰＵに代行させる例を示したが、アクセスに要する時間に基づいて非常駐型の仮想ＣＰＵに代行させるか否かを選択する構成とすることができる。具体的には、事前テスト等により計測した占有型の物理デバイスへのアクセスに要する最大待ち時間を予め設定し、最大待ち時間が予め設定した規定時間よりも長い場合にはアクセスする処理を非常駐型の仮想ＣＰＵに代行させる一方、最大待ち時間が規定時間よりも短い場合にはアクセスする処理を常駐型の仮想ＣＰＵで実行する構成とすることができる。
　これにより、例えばアクセスを代行させる処理に要する時間がアクセスを代行させることで得られる物理ＣＰＵの利用時間よりも長くなる場合等にはアクセスを代行させないことが可能となり、仮想化環境のパフォーマンスを意図せずに低下させてしまうことを抑制できる。
　各実施形態では占有型の物理デバイスとしてＧＰＵ１０５を例示したが、本実施形態のアクセス方法は、ＧＰＵ１０５に限定されず、例えばＧＰＵ１０５を画像処理以外の処理に応用するGeneral-purpose computing on graphics processing units（以下、ＧＰＧＰＵ）や画像処理専用のImage processing unit（以下、ＩＰＵ）、あるいはベンダー独自のインターフェースを有するようなデバイスへのアクセスにも適用することができる。
　各実施形態では、４つの物理ＣＰＵを２つの仮想マシン３００に割り当てた例を示したが、仮想マシン３００の数は、これに限定されない。構築する仮想マシン３００の数をＭとすると、ハードウェア１００が備える物理ＣＰＵの数がＭ以上であれば、各仮想マシン３００に重複無く物理ＣＰＵを割り当てることができる。つまり、ハイパーバイザ２００上で２つ以上の仮想マシン３００を動作させ、複数の仮想マシン３００に物理ＣＰＵを重複しないように割り当てる構成とすることができる。このとき、各仮想マシン３００には割り当てられた物理ＣＰＵの数と同じ常駐型の仮想ＣＰＵを設け、対象となる占有型の物理デバイスの数と同じ非常駐型の仮想ＣＰＵを設け、上記したアクセス方法を適用することで、仮想化環境１のパフォーマンスが低下することを抑制することができる。
　本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に含まれるものである。

Claims (7)

  1. 　仮想化環境（１）においてデバイスにアクセスするためのアクセス方法であって、
    　前記仮想化環境（１）は、物理ＣＰＵ（１０１、１０２、１０３、１０４）および物理デバイス（１０５）を備えたハードウェア（１００）と、前記ハードウェア上で動作するハイパーバイザ（２００）と、前記ハイパーバイザ上で動作し、前記物理ＣＰＵを仮想化した仮想ＣＰＵ（３０１、３０２、３０３）および前記物理デバイスを仮想化した仮想デバイス（３０５）を備える仮想マシン（３００）とを含み、
    　前記ハードウェアは、アクセスが要求されてからその要求に対する応答を返すまでアクセス元のＣＰＵを占有する占有型の前記物理デバイス（１０５）を備えており、
    　前記仮想マシン上に、常には前記物理ＣＰＵが割り当てられている常駐型の前記仮想ＣＰＵ（３０１、３０２）と、常には前記物理ＣＰＵが割り当てられていない非常駐型の前記仮想ＣＰＵ（３０３）とを実装し、
    　常駐型の前記仮想ＣＰＵ（３０１、３０２）から占有型の前記物理デバイス（１０５）に対応する前記仮想デバイス（３０５）にアクセスする際、アクセスする処理を非常駐型の前記仮想ＣＰＵ（３０３）に代行させるアクセス方法。
  2. 　前記仮想マシン上に、占有型の前記仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部（３１１）と割り込みハンドラ部（３１２）とを含み、前記システムコール部と前記割り込みハンドラ部とのそれぞれに前記仮想デバイスにアクセスするアクセス部分（ｓ、ｉ）が設けられている仮想ドライバ（３１０）を実装し、
    　前記アクセス部分を非常駐型の前記仮想ＣＰＵで実行する請求項１に記載のアクセス方法。
  3. 　前記仮想マシン上に、占有型の前記仮想デバイスにアクセスするためのドライバソフトウェアであって、システムコール部と割り込みハンドラ部とを含み、前記システムコール部から行われる前記仮想デバイスへのアクセスを処理するアクセス部分（ｓ）を、専用タスク（ＴＳ）として呼び出し可能に構成した仮想ドライバ（４１０）を実装し、
    　前記専用タスクを非常駐型の前記仮想ＣＰＵで実行する請求項１に記載のアクセス方法。
  4. 　前記ハイパーバイザ上のハイパーバイザスケジューラ（２０１）に、前記仮想マシンに加えて、占有型の前記物理デバイスに直接的にアクセス可能に構成したタスクをスケジューリング対象として配置し、
    　常駐型の前記仮想ＣＰＵから占有型の前記物理デバイスに対応する前記仮想デバイスにアクセスする際、前記専用タスクを非常駐型の前記仮想ＣＰＵで実行し、
    　非常駐型の前記仮想ＣＰＵからアクセスの要求があった際、前記ハイパーバイザ上に配置したタスクを用いて占有型の前記物理デバイスにアクセスする請求項１に記載のアクセス方法。
  5. 　占有型の前記物理デバイスへのアクセスに要する最大待ち時間を予め設定し、
    　前記最大待ち時間が予め設定した規定時間よりも長い場合にはアクセスする処理を非常駐型の前記仮想ＣＰＵに代行させる一方、前記最大待ち時間が前記規定時間よりも短い場合にはアクセスする処理を常駐型の前記仮想ＣＰＵで実行する請求項１から４のいずれか一項に記載のアクセス方法。
  6. 　前記ハイパーバイザ上で２つ以上の仮想マシンを動作させ、
    　複数の前記仮想マシンに前記物理ＣＰＵを重複しないように割り当てる請求項１から５のいずれか一項に記載のアクセス方法。
  7. 　前記仮想マシンに、前記ハードウェアが備える前記物理デバイスと同じ数の非常駐型の前記仮想ＣＰＵを実装する請求項１から６のいずれか一項に記載のアクセス方法。
PCT/JP2019/021077 2018-07-03 2019-05-28 仮想化環境におけるデバイスへのアクセス方法 Ceased WO2020008757A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/129,762 US12032983B2 (en) 2018-07-03 2020-12-21 Method of accessing device in virtual environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018126799A JP7196439B2 (ja) 2018-07-03 2018-07-03 仮想化環境におけるデバイスへのアクセス方法
JP2018-126799 2018-07-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/129,762 Continuation US12032983B2 (en) 2018-07-03 2020-12-21 Method of accessing device in virtual environment

Publications (1)

Publication Number Publication Date
WO2020008757A1 true WO2020008757A1 (ja) 2020-01-09

Family

ID=69059578

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/021077 Ceased WO2020008757A1 (ja) 2018-07-03 2019-05-28 仮想化環境におけるデバイスへのアクセス方法

Country Status (3)

Country Link
US (1) US12032983B2 (ja)
JP (1) JP7196439B2 (ja)
WO (1) WO2020008757A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12314732B2 (en) * 2022-12-13 2025-05-27 Ati Technologies Ulc Continuity of service for virtualized device after resumption from hibernation
JP2024085626A (ja) 2022-12-15 2024-06-27 株式会社デンソー コンピュータシステム、異常対処方法
JP2024085627A (ja) 2022-12-15 2024-06-27 株式会社デンソー コンピュータシステム、異常対処方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05250263A (ja) * 1992-03-05 1993-09-28 Hitachi Ltd 仮想プロセッサ方式及び不揮発化記憶方式
JP2006209386A (ja) * 2005-01-27 2006-08-10 Hitachi Ltd 仮想計算機システム及びその外部割込み制御方法
WO2017094132A1 (ja) * 2015-12-02 2017-06-08 株式会社日立製作所 計算機および計算機の制御方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10261875B2 (en) * 2013-12-18 2019-04-16 Qualcomm Incorporated Runtime optimization of multi-core system designs for increased operating life and maximized performance
CN106462451B (zh) 2014-06-20 2019-11-12 华为技术有限公司 虚拟化平台处理中断方法和相关设备
US9558041B2 (en) * 2014-09-05 2017-01-31 Telefonaktiebolaget L M Ericsson (Publ) Transparent non-uniform memory access (NUMA) awareness
KR102301230B1 (ko) * 2014-12-24 2021-09-10 삼성전자주식회사 가상화된 gpu들에 대한 스케줄링을 수행하는 방법 및 이를 위한 디바이스
US9678901B2 (en) * 2015-11-16 2017-06-13 International Business Machines Corporation Techniques for indicating a preferred virtual processor thread to service an interrupt in a data processing system
WO2017166207A1 (en) * 2016-03-31 2017-10-05 Intel Corporation Cooperative scheduling of virtual machines
US10228981B2 (en) * 2017-05-02 2019-03-12 Intel Corporation High-performance input-output devices supporting scalable virtualization
CN109144679B (zh) * 2017-06-27 2022-03-29 华为技术有限公司 中断请求的处理方法、装置及虚拟化设备
US10372497B1 (en) * 2017-09-05 2019-08-06 Parallels International Gmbh Offloading GPU computations for computers and virtual machines
US10318456B2 (en) * 2017-11-06 2019-06-11 International Business Machines Corporation Validation of correctness of interrupt triggers and delivery

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05250263A (ja) * 1992-03-05 1993-09-28 Hitachi Ltd 仮想プロセッサ方式及び不揮発化記憶方式
JP2006209386A (ja) * 2005-01-27 2006-08-10 Hitachi Ltd 仮想計算機システム及びその外部割込み制御方法
WO2017094132A1 (ja) * 2015-12-02 2017-06-08 株式会社日立製作所 計算機および計算機の制御方法

Also Published As

Publication number Publication date
US12032983B2 (en) 2024-07-09
JP2020008933A (ja) 2020-01-16
JP7196439B2 (ja) 2022-12-27
US20210149705A1 (en) 2021-05-20

Similar Documents

Publication Publication Date Title
US10191759B2 (en) Apparatus and method for scheduling graphics processing unit workloads from virtual machines
EP3039540B1 (en) Virtual machine monitor configured to support latency sensitive virtual machines
US9058183B2 (en) Hypervisor isolation of processor cores to enable computing accelerator cores
CN114138422B (zh) 可扩展性的NVMe存储虚拟化方法和系统
CN111324432B (zh) 处理器调度方法、装置、服务器及存储介质
GB2525003A (en) Data Processing Systems
WO2012016439A1 (zh) 业务管理方法和装置、以及设备
JP2005327279A5 (ja)
JP2009508183A (ja) 仮想マシン・モニタと、ａｃｐｉ準拠ゲスト・オペレーティング・システムとの間の双方向通信のための方法、装置及びシステム
US10241829B2 (en) Information processing device, information processing method, recording medium, calculation processing device, calculation processing method
JP7829565B2 (ja) 早期解放を伴うレジスタ圧縮
US12032983B2 (en) Method of accessing device in virtual environment
US20090241112A1 (en) Recording medium recording virtual machine control program and virtual machine system
JP2006099332A (ja) 情報処理装置、プロセス制御方法、並びにコンピュータ・プログラム
JP5131269B2 (ja) マルチプロセッシングシステム
CN103970608A (zh) 用于借助至少两个虚拟机来管理计算机资源的方法及虚拟化控制器
US8402191B2 (en) Computing element virtualization
US10922149B2 (en) System comprising a plurality of virtualization systems
US20250173172A1 (en) Adaptive eviction of idle virtual functions for maximum usage of a parallel processing unit
JP4730386B2 (ja) 仮想計算機装置、計算資源活用方法、および、プログラム
KR101534139B1 (ko) 가상머신을 위한 협력 스케줄링 방법
JP2009266050A (ja) 情報処理装置
JP3585956B2 (ja) 情報処理装置及びその方法
WO2019052643A1 (en) STORAGE I / O PROJECTED IN MEMORY
CN118377576A (zh) 一种控制智能穿戴设备工作模式的轻量级虚拟化操作系统

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19831348

Country of ref document: EP

Kind code of ref document: A1