DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The disclosure is objected to because of the following informalities:
Paragraph 0001 of the specification includes a claim of priority. An update or revision of the specification may be required in the event that it is applicable.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2014/0068605 A1 to Tsirkin et al. in view of U.S. Pub. No. 2014/0237149 A1 to Jacob.
As to claim 1, Tsirkin teaches a device hotplug method, comprising:
in response to a hotplug request received by a virtual machine monitor for a virtual target device in a virtual machine (Block 201), determining operation resource information corresponding to the hotplug request using the virtual machine monitor, wherein the operation resource information comprises resource information needed for performing hotplug on the virtual target device (the request may specify an identifier of a particular virtual processor of VM 130, or a virtual proximity domain for the additional virtual processor, or both) (“…At block 201, hypervisor 125 receives a request from guest operating system 135 for an additional virtual processor (i.e., a processor hotplug request). In some embodiments, the request may specify an identifier of a particular virtual processor of VM 130, or a virtual proximity domain for the additional virtual processor, or both. In one embodiment, the request is received by policy manager 128 of hypervisor 125. It should be noted that for embodiments in which memory 170 is non-uniform memory access (NUMA), the virtual proximity domain may be a particular virtual NUMA node of VM 130…At block 202, hypervisor 125 obtains one or more measures of utilization for one or more CPUs 160. Such measures of utilization may include the percentage of time that a particular CPU 160 is non-idle, the number of virtual processors that are run by a particular CPU 160, the number of threads in a runnable state executed by a particular CPU 160, and so forth. In one embodiment, block 202 is performed by policy manager 128 of hypervisor 125…At block 203, hypervisor 125 determines, based on a processor hotplug policy, whether or not to grant the processor hotplug request. In one embodiment, the policy specifies one or more conditions pertaining to one or more measures of CPU utilization, and hypervisor 125 determines whether allocating an additional virtual processor to VM 130 will violate any of the conditions of the policy. In some embodiments, the policy may be defined by an administrator (e.g., via a configuration file, via a graphical user interface, etc.), while in some other embodiments the policy may be hard-coded in policy manager 128 of hypervisor 125…Block 204 branches based on the determination of block 204. If hypervisor 125 determined that the request is not to be granted, execution proceeds to block 205, otherwise execution continues at block 206…At block 206, hypervisor 125 selects one of a plurality of proximity domains for a CPU 160 that will run the additional virtual processor. In some embodiments, hypervisor 125 may select a proximity domain with a CPU that is currently running a virtual processor of the virtual proximity domain specified in the guest OS's request. In some other embodiments, hypervisor 125 may select a proximity domain with a CPU that has previously run a virtual processor of the virtual proximity domain specified in the guest OS's request. In still other embodiments, hypervisor 125 may select a proximity domain with a CPU that is scheduled to run, in the future, a virtual processor of the virtual proximity domain specified in the guest OS's request…” paragraphs 0027-0029/0032).
Tsirkin is silent with reference to storing the operation resource information into an operation queue of a preset hotplug device, and sending an interrupt trigger signal to a sub-operating system of the virtual machine, wherein the preset hotplug device is an information transmission channel between the virtual machine monitor and the sub-operating system, and is configured to transmit information related to the hotplug request and
acquiring the operation resource information from the operation queue by using the sub-operating system when the interrupt trigger signal is detected by the sub-operating system, and executing a hotplug operation for the virtual target device according to the operation resource information.
Jacob teaches storing the operation resource information into an operation queue of a preset hotplug device (Queue 140-1/2/Resource A (the encryption coprocessor or CPU 101D)) (“…The hypervisor 136-1 is an example of, and is generically referred to by, the hypervisor 136 (FIG. 1). The hypervisor 136-1 comprises a queue 140-1, which is assigned to the shared resource A 101D, and a queue 140-2, which is assigned to the shared resource B. The queues 140-1 and 140-2 are examples of, and are generically referred to by, the queues 140 (FIG. 1). The queue 140-1 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the resource A (the encryption coprocessor or CPU 101D). For example, the queue 140-1 comprises request A at a time that is after time 1 and before time 2 (between the time that hypervisor 136 receives the request A 142-1 from the virtual machine 133 and sends the request A 142-2 to the shared resource A 101D). As another example, the queue 140-1 comprises the request B at a time between time X and time 4 (between the time that the hypervisor 136-1 receives the request B 142-7 from the virtual machine 134 and the time that the hypervisor 136-1 sends the request B 142-4 to the shared resource A 101D). The queue 140-2 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the shared resource B (the network interface unit 114)…” paragraph 0043), and sending an interrupt trigger signal to a sub-operating system of the virtual machine, wherein the preset hotplug device is an information transmission channel between the virtual machine monitor and the sub-operating system, and is configured to transmit information related to the hotplug request (Completion Interruption 143) and
acquiring the operation resource information from the operation queue by using the sub-operating system when the interrupt trigger signal is detected by the sub-operating system (Interrupt Engine 252), and executing a hotplug operation for the virtual target device according to the operation resource information (Requests A/B 142) (“…The shared resource A 101D comprises an encryption engine 250, which performs the requests 142-2, 142-3, and 142-4, and an interrupt engine 252, which sends the completion interrupt 143-5. Thus, in various embodiments, the encryption engine 250 may be busy performing requests while the interrupt engine 252 is busy sending completion interrupts 143, the encryption engine 250 may be busy performing requests while the interrupt engine 252 is idle, the encryption engine 250 may be idle while the interrupt engine 252 is busy sending a completion interrupt 143, or both the encryption engine 250 and the interrupt engine 252 may be idle…The hypervisor 136-1 is an example of, and is generically referred to by, the hypervisor 136 (FIG. 1). The hypervisor 136-1 comprises a queue 140-1, which is assigned to the shared resource A 101D, and a queue 140-2, which is assigned to the shared resource B. The queues 140-1 and 140-2 are examples of, and are generically referred to by, the queues 140 (FIG. 1). The queue 140-1 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the resource A (the encryption coprocessor or CPU 101D). For example, the queue 140-1 comprises request A at a time that is after time 1 and before time 2 (between the time that hypervisor 136 receives the request A 142-1 from the virtual machine 133 and sends the request A 142-2 to the shared resource A 101D). As another example, the queue 140-1 comprises the request B at a time between time X and time 4 (between the time that the hypervisor 136-1 receives the request B 142-7 from the virtual machine 134 and the time that the hypervisor 136-1 sends the request B 142-4 to the shared resource A 101D). The queue 140-2 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the shared resource B (the network interface unit 114)…” paragraphs 0042/0043).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Tsirkin with the teaching of Jacob because the teaching of Jacob would improve the system of Tsirkin by providing a technique for data structure for storing data for later retrieval.
As to claims 8 and 15, see the rejection of claim 1 above, expect for at least one processor, at least one memory and a non-transitory computer readable storage medium.
Tsirkin teaches at least one processor (CPU 1601-N), at least one memory (Main Memory 170) and a non-transitory computer readable storage medium (Storage Device 180).
Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2012/0174097 to Levin et al. in view of U.S. Pub. No. 20140237149 A1 to Jacob.
As to claim 1, Levin teaches a device hotplug method, comprising:
in response to a hotplug request received by a virtual machine monitor for a virtual target device in a virtual machine (request), determining operation resource information corresponding to the hotplug request using the virtual machine monitor, wherein the operation resource information comprises resource information needed for performing hotplug on the virtual target device (the request may specify an identifier of a particular virtual processor of VM 130, or a virtual proximity domain for the additional virtual processor, or both) (“…A request to allocate more memory resources may be originated from the virtualization layer, for example from the virtual machine interface module 111. In such an embodiment, the virtual machine interface module 111 analyzes the memory load of each virtual guest 103 and considers releasing memory resources which are available on the host platform 100. Adding resources may be done to reallocate resources to balance resources across the virtual guests 101 so as to make changes which do not depend on demands of virtual guests 101 but also on available resources on the host platform 100…A request to allocate more memory resources may be originated from the virtual guest itself, for example from the OS monitoring module 106, which may detect more sudden and immediate demand for additional memory. The OS monitoring module 106 communicates with the virtual machine interface module 111 to verify that it is possible to allocate more memory resources. For example, FIG. 4 depicts a flowchart of a process that is implemented by the OS monitoring module 106 to add resources to the hosting virtual guest 103, according to some embodiments of the present invention. As shown at 352, 352, the OS monitoring module 106 monitors and detects when there is a demand for an additional resource. Then, as shown at 353, 354 the OS monitoring module 106 verifies with the virtual machine interface module 111 if more respective resources are available. If so, the guest OS 103 is prepared and the resource is added, with coordination with the virtual machine interface module 111, as shown at 355, 256. If no resources are available, this process ends, as shown at 357. The process may be repeated any number of times when the virtual guest 101 is hosted and executed on the host platform 100…The OS monitoring module 106 is optionally set to verify that enough free resources are available by communicating with the virtual machine interface module 111 and updates the respective guest OS 103 about the addition of a new memory block…” paragraphs 0086-0088);
sending an interrupt trigger signal to a sub-operating system of the virtual machine (Each BIOS interface module 107 intercepts the interrupts, performs respective operations inside the BIOS 104, and notifies the guest operating system 103 about the respective operations) (“…The virtual machine interface module 111 communicates with the interface BIOS modules 107 by invoking virtual hardware interrupts on the respective virtual guests 101. The virtual hardware interrupts indicate the required addition or removal of virtual resources, which are to be added to and/or removed from the virtual guest 101. Each BIOS interface module 107 intercepts the interrupts, performs respective operations inside the BIOS 104, and notifies the guest operating system 103 about the respective operations. For example, once a resource, such as a new virtual memory block, has been allocated by the virtual machine interface module 111, it is attached to the virtual guest 101 and the BIOS interface module 107 notifies the guest operating system 103 asserting a notification into the advanced configuration and power interface (ACPI) device in the BIOS which handles memory operations, for example the `PNP0C80`. For example, an ACPI interrupt named PNP0C80 is called. The guest OS 103, which optionally supports ACPI, detects this change. For example, Linux.TM. OS detects the change and runs an appropriate udev script to add the new memory block into the guest OS 103. If the guest OS does not support ACPI, the OS monitoring modules 106 and optionally the driver interface module 108 perform the change using OS APIs. Other operations may be performed similarly, where the type of the virtual resource which is allocated or released and the name of the ACPI interrupt are changed…Optionally, in order to notify the virtual guest 103 about the allocation, as shown at 307, a hardware interrupt that is defined to be intercepted by the BIOS interface module 107 is sent. The hardware interrupt is optionally a `standard` interrupt that is set to notify the virtual hardware regarding a new resource, such as processing unit. For clarity, it should be noted that a new process may be part of a resource…” paragraphs 0048/0048/0079-0081), wherein the preset hotplug device is an information transmission channel between the virtual machine monitor and the sub-operating system, and is configured to transmit information related to the hotplug request (a `backdoor` protocol/ transmission control protocol internet protocol (TCP/IP) messages) (“…Alternatively, the VMM is modified to perform the addition and the removal mentioned above. In addition, the virtual machine interface module 111 also communicates with the monitoring modules 99 to update the virtual resources which are managed by the Guest OS 103. In such a manner, the monitoring modules 99 may be instructed to change the virtual resources which are used by the respective Guest OSs 103, for example to remove and/or to add a resource, such as a memory block and/or a computing unit, from the virtual resources which are used by the Guest OS 103. The communication between the monitoring modules 99 and the virtual machine interface module 111 may be performed using a `backdoor` protocol provided by the VMM 110, such as the `VX` port used by VMware.TM., so that the communications between the guest OS 103 and the monitoring modules 99 are performed within the VMM 110 itself…The virtual machine interface module 111 communicates with the OS monitoring modules 106 by a communication with the Guest OS 103. The communication may be done by any transport that is available for the guest OS 103, for example transmission control protocol internet protocol (TCP/IP) messages, internal host-guest transport, and/or any other transport that is able to communicate command messages. The virtual machine interface module 111 notifies the OS monitoring modules 106 of any required additions and removals of virtual memory. In addition, the virtual machine interface module 111 optionally monitors the resource usage of virtual machines 101 using an API that is provided by the virtualization layer. The virtual machine interface module 111 aggregates the collected resource usage data which consists of one or more of the following:…” paragraphs 0046/0049); and
executing a hotplug operation for the virtual target device according to the operation resource information (“…Optionally, as shown at 308, if the new resource is not accessed or used by the virtual guest 103, an alert about a new resource, such as a new processing unit, is sent to the virtual guest 103. This forces the respective guest OS 103 to start working with the newly allocated resource. For example, the forcing assures that the guest OS 103 performs internal steps needed to initialize the resource, such as running a script on the virtual guest 103 which process the interrupt which informs the guest OS 103 about the new hardware and calls the appropriate OS API to register the new hardware within the guest OS 103 and/or add the resource to an allocation mechanism, for example a processing unit to a task scheduling process. Optionally, as shown at 309, the alerting is performed via the OS monitoring module 106, which uses an OS API and/or the driver interface module 108 to add the resource to the guest OS 103, as shown at 310…” paragraph 0081).
Levin is silent with reference to storing the operation resource information into an operation queue of a preset hotplug device, and
acquiring the operation resource information from the operation queue by using the sub-operating system when the interrupt trigger signal is detected by the sub-operating system.
Jacob teaches storing the operation resource information into an operation queue of a preset hotplug device (Queue 140-1/2/Resource A (the encryption coprocessor or CPU 101D)) (“…The hypervisor 136-1 is an example of, and is generically referred to by, the hypervisor 136 (FIG. 1). The hypervisor 136-1 comprises a queue 140-1, which is assigned to the shared resource A 101D, and a queue 140-2, which is assigned to the shared resource B. The queues 140-1 and 140-2 are examples of, and are generically referred to by, the queues 140 (FIG. 1). The queue 140-1 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the resource A (the encryption coprocessor or CPU 101D). For example, the queue 140-1 comprises request A at a time that is after time 1 and before time 2 (between the time that hypervisor 136 receives the request A 142-1 from the virtual machine 133 and sends the request A 142-2 to the shared resource A 101D). As another example, the queue 140-1 comprises the request B at a time between time X and time 4 (between the time that the hypervisor 136-1 receives the request B 142-7 from the virtual machine 134 and the time that the hypervisor 136-1 sends the request B 142-4 to the shared resource A 101D). The queue 140-2 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the shared resource B (the network interface unit 114)…” paragraph 0043), and
acquiring the operation resource information from the operation queue by using the sub-operating system when the interrupt trigger signal is detected by the sub-operating system (Interrupt Engine 252) (“…The shared resource A 101D comprises an encryption engine 250, which performs the requests 142-2, 142-3, and 142-4, and an interrupt engine 252, which sends the completion interrupt 143-5. Thus, in various embodiments, the encryption engine 250 may be busy performing requests while the interrupt engine 252 is busy sending completion interrupts 143, the encryption engine 250 may be busy performing requests while the interrupt engine 252 is idle, the encryption engine 250 may be idle while the interrupt engine 252 is busy sending a completion interrupt 143, or both the encryption engine 250 and the interrupt engine 252 may be idle…The hypervisor 136-1 is an example of, and is generically referred to by, the hypervisor 136 (FIG. 1). The hypervisor 136-1 comprises a queue 140-1, which is assigned to the shared resource A 101D, and a queue 140-2, which is assigned to the shared resource B. The queues 140-1 and 140-2 are examples of, and are generically referred to by, the queues 140 (FIG. 1). The queue 140-1 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the resource A (the encryption coprocessor or CPU 101D). For example, the queue 140-1 comprises request A at a time that is after time 1 and before time 2 (between the time that hypervisor 136 receives the request A 142-1 from the virtual machine 133 and sends the request A 142-2 to the shared resource A 101D). As another example, the queue 140-1 comprises the request B at a time between time X and time 4 (between the time that the hypervisor 136-1 receives the request B 142-7 from the virtual machine 134 and the time that the hypervisor 136-1 sends the request B 142-4 to the shared resource A 101D). The queue 140-2 comprises requests that the hypervisor 136-1 has received from the virtual machine 133 and/or 134, but has not yet sent to the shared resource B (the network interface unit 114)…” paragraphs 0042/0043).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Levin with the teaching of Jacob because the teaching of Jacob would improve the system of Levin by providing a technique for data structure for storing data for later retrieval.
As to clams 8 and 15, see the rejection of claim 1 above, expect for at least one processor, at least one memory and a non-transitory computer readable storage medium.
Levin teaches at least one processor (“…data processor…” paragraph 0030), at least one memory (“…volatile memory…” paragraph 0030) and a non-transitory computer readable storage medium (“…magnetic hard-disk and/or removable media…” paragraph 0030).
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2012/0174097 to Levin et al. in view of U.S. Pub. No. 2014/0237149 A1 to Jacob as applied to claims 1, 8 and 15 above, and further in view of U.S. Pub. No. 2016/0179735 A1 to Zou et al.
As to claim 3, Levin as modified by Jacob teaches the method according to claim 1, wherein the determining operation resource information corresponding to the hotplug request using the virtual machine monitor (the request may specify an identifier of a particular virtual processor of VM 130, or a virtual proximity domain for the additional virtual processor, or both) however it is silent with reference to establishing communication connection with the virtual target device, and determining a resource feature structure supported by the virtual target device using the communication connection; and
configuring the operation resource information for the virtual target device according to the hotplug request and the resource feature structure.
Zou teaches establishing communication connection with the target device (PCIE devices), and determining a resource feature structure supported by the virtual target device using the communication connection (socket interface); and
configuring the operation resource information for the target device according to the hotplug request and the resource feature structure (“…Specifically, in an embodiment according to the present disclosure, hotplug management module 120 may manage the PCIE devices based on two libraries provided by an underlying operating system. In one embodiment, one is a libipmi library that may provide APIs for performing operations on PCIE devices, such as powering on, powering off, state checking, setting LED, and the like. In a further embodiment, the other is a libpci library that may provide an API for performing PCIE protocol layer-related hotplug operations. In a further embodiment, a PCIE related operations may include, for example, scanning a PCIE device, accessing a PCIE register, etc. In a further embodiment, hotplug management module 120 performs PCIE configuration/un-configuration operations in a kernel by means of sysfs, including loading/unloading a driver of a corresponding type of PCIE device, PCI bus scan, PCI resource assignment/de-assignment, etc…Referring back to FIG. 2, communication of hotplug management module 120 with HG service modules 103a-103e, user command input interface module 102a, and testing & debugging tool 102b may use any type of inter-process communication (IPC) mechanism, but preferably uses a socket interface. This may implement it as a single thread and event-driven model, and a response time, for example, may be MAX (D1, D2, D3 . . . DN). Through use of a socket interface, hotplug management module 120 may act as a central server, while peripheral modules such as the HG service module, user command interface module 102a, and testing & debugging tool 102b may act as a client, thereby simplifying the model. However, this needs to consider information encoding and decoding and handle timeout appropriately. Moreover, hotplug management module 120 needs to process netlink sockets. Through use of sockets, an I/O multiplexing method (selection, poll, enhanced poll) may be adopted, thereby implementing the system in a uniform manner…” paragraphs 0034/0061).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Levin and Jacob with the teaching of Zoc because the teaching of Zoc would improve the system of Levin and Jacob by providing a mechanism for setting up a communication channel to another host system.
As to claims 10 and 17, see the rejection of claim 3 above.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2012/0174097 to Levin et al. in view of U.S. Pub. No. 2014/0237149 A1 to Jacob as applied to claims 1, 8 and 15 above, and further in view of U.S. Pub. No. 2023/0041845 A1 to Tsirkin et al. (hereinafter referred to as Tsirkin’845).
As to claim 4, Levin as modified by Jacob teaches the method according to claim 1, wherein prior to determining operation resource information corresponding to the hotplug request using the virtual machine monitor, the method further comprises: starting the preset hotplug device deployed in the virtual machine monitor in a process of initializing the virtual machine monitor (“…Optionally, the host controller communicates with each the monitoring module via a connection channel with a guest operating system of a respective of the plurality of guest virtual machines…” paragraph 0024/claim 19).
Levin as modified by Jacob does not teach starting the secure container in response to a container startup request, and
initializing the virtual machine monitor and the sub-operating system;.
Tskrkin”845 teaches wherein prior to determining operation resource information corresponding to the hotplug request using the virtual machine monitor, the method further comprises:
starting the secure container in response to a container startup request (Container management component 124 may create a nested container within another container to run a child virtual machine, by sending a request to hypervisor 120 from the parent virtual machine), and
initializing the virtual machine monitor and the sub-operating system (After creation of the nested container, the child virtual machine is ran within the nested container) (“…Container management component 124 may create a nested container within another container to run a child virtual machine, by sending a request to hypervisor 120 from the parent virtual machine ran in one of container 105A-C. To create the nested container, responsive to receiving the request by the hypervisor 120, the hypervisor 120 performs a container application programming interface (“API”) call to create a container. The container API refers to software tools utilized to manage container creation and management of resources for the created containers. As a result, of receiving the request, the hypervisor 120 creates a nested container to be nested within the container 105A-C of the requesting parent virtual machine. After creation of the nested container, the child virtual machine is ran within the nested container. Accordingly, each child virtual machine being ran in a nested container imposes little to no overhead because programs within each of the containers may use the underlying hypervisor 120 to execute system calls, as will be discussed in more detail in regards to FIG. 2…Method 300 may be performed by processing devices of a server device or a client device and may begin at block 310. At block 310, a host computer system may run, by a host computer system, a hypervisor managing a first virtual machine implemented by a first container with a first set of resources. The hypervisor may create the first container and enable the first virtual machine to run within the first container. As described previously, the hypervisor provides the first set of resources to the first container to be used by the first virtual machine according to the resources requirements of the first virtual machine.
[0037] At block 320, the host computer system may create, by the hypervisor, a second container implementing the second virtual machine, wherein the second container is nested within the first container. As described previously, creating the second virtual machine is performed responsive to receiving a request from the first virtual machine. Once the nested container is created, the hypervisor enables a second virtual machine to run within the second container which is nested in the first container…At block 330, the host computer system may identify, by the first virtual machine of the first container, a second set of resources comprising one or more of the first set of resources to assign to the second container. In some embodiment, the identified one or more of the first set of resources refers to all of the resources from the first set of resources. In some embodiments, the identified one or more of the first set of resources refers to one or more of the first set of resources identified by the request (e.g., container API call) which determined the type of resources needed by the nested container and the amount of resources needed by the nested container. Based on the type and amount of resources needed by the nested container one or more of the first set of resources may be identified as resources to be assigned to the nested container. As described previously, the hypervisor when creating the second container assigns one or more of the first set of resources to the second container. Prior to assigning one or more of the first set of resources to the second container, the hypervisor receives from the first virtual machine one or more of the first set of resources which determines the resources that the second virtual machine needs to run. The second set of resources is a subset of the first set of resources. To determine the one or more of the first set of resources to be used by the second virtual machine, the first virtual machine of the first container selects one or more of the first set of resources to assign to the second container by limiting the first set of resources to one or more of the first set of resources…At block 340, the host computer system may assign, by the hypervisor, the second set of resources to the second container. To assign the second set of resources to the second container the first virtual machine sends a request to the hypervisor to assign the one or more of the first set of resources of the first container to the second container (i.e., responsive to receiving the request to assign resources by the hypervisor, the hypervisor performs a container API call to assign the identified one or more of the first set of resources to the second container). The second set of resources are unavailable to the first container. For example, the one or more of the first set of resources that have been assigned to the second container is unable be used by the first container. Accordingly, the first set of resources can only be used by the first container or the second container…” paragraphs 0025/00360-0039).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Levin and Jacob with the teaching of Tskrkin”845 because the teaching of Tskrkin”845 would improve the system of Levin and Jacob by providing a mechanism for initializing resources for executing tasks.
As to claims 11 and 18, see the rejection of claim 4 above.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2012/0174097 to Levin et al. in view of U.S. Pub. No. 2014/0237149 A1 to Jacob as applied to claims 1 and 8 above, and further in view of C.N. No. 112330229 A to Jiang et al.
As to claim 7, Levin as modified by Jacob teaches the method according to claim 1, however it is silent with reference to wherein the executing a hotplug operation for the virtual target device according to the operation resource information comprises:
determining operation logic according to an operation type indicated by the operation resource information and a device type of the virtual target device; and
executing the hotplug operation corresponding to the operation type for the virtual target device according to the operation logic and the operation resource information.
Jiang teaches wherein the executing a hotplug operation for the virtual target device according to the operation resource information comprises:
determining operation logic according to an operation type indicated by the operation resource information (if the function type is the first type) and a device type of the virtual target device (virtual central processor VCPU; and
executing the hotplug operation corresponding to the operation type for the virtual target device according to the operation logic and the operation resource information (mapping) (“…A resource scheduling method, wherein the method is executed by an electronic device, the electronic device is installed with a plurality of virtual machines, each virtual machine is installed with an application, the method comprises: if the application is started, obtaining the function request generated by the application; determining the function type according to the function request; the function type comprises at least two types; distributing resource to the target virtual machine corresponding to the application according to the function type…The resource scheduling method according to claim 1, wherein the step of allocating resource to the target virtual machine corresponding to the application according to the function type comprises: if the function type is the first type, the virtual central processor VCPU of the target virtual machine is corresponding to one or more kernels of the physical central processor PCPU of the electronic device; mapping the virtual memory address of the target virtual machine and the physical memory address of the electronic device one by one; and the mapping relationship between the virtual memory address and the physical memory address is stored in the preset page table…The resource scheduling method according to claim 1, wherein the step of allocating resource to the target virtual machine corresponding to the application according to the function type comprises: if the function type is the second type, the VCPU of the target virtual machine is corresponding to one or more cores of the PCPU of the electronic device; mapping the virtual memory address of the target virtual machine and the physical memory address of the electronic device one by one; storing the mapping relationship between the virtual memory address and the physical memory address in the preset page table; and setting the calling authority of the kernel; the highest call authority of the target virtual machine; setting the use authority of the physical memory address as only the target virtual machine…” claims 1-3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Levin and Jacob with the teaching of Jiang because the teaching of Jiang would improve the system of Levin and Jacob by providing a technique for dedicating device to function type for seamless execution.
As to claim 14, see the rejection of claim 7 above.
Allowable Subject Matter
Claims 2, 5, 6, 9, 12, 13, 16, 19, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for allowance
The following is an examiner’s statement of reasons for allowance:
The closest prior art of records, (U.S. Pub. No. 2012/0174097 to Levin et al., U.S. Pub. No. 2014/0237149 A1 to Jacob and U.S. Pub. No. 2014/0068605 A1 to Tsirkin et al.), taken alone or in combination do not specifically disclose or suggest the claimed recitations (claims 2, 5, 6, 9, 12, 13, 16, 19, and 20), when taken in the context of claims as a whole.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2014/0068603 A1 to Tsirkin et al. and directed to a system and method for allocating additional virtual processors to virtual machines (referred to as "automatic processor hotplug").
U.S. Pub. No. 2009/0133016 A1 to Brown et al. and directed to a method for initiating a hot-plug operation for adding a new I/O endpoint to the data processing system.
U.S. Pub. No. 2020/0174821 A1 to Liopoulos et al. and directed to a system includes a processor and a memory, resources selected from processing resources and memory resources.
C.N. No. 110998530 A to Liopoulos et al. and directed to a virtual machine resource allocation system, method and computer program.
E.P. No. 2867772 B1 to Chin et al. and directed to dynamic resource allocation for virtual machines.
U.S. Pub. No. 2015/0149996 A1 to Tsirkin et al. and directed to a method involves maintaining a pool of input/output resources for assignment to virtual peripheral component interconnect devices through a hypervisor executable on a host.
U.S. No. 2022/0326979 A1 to Dong et al. and directed to methods and apparatus to process commands from virtual machines.
U.S. Pub. No. 2021/0216344 A1 to Tsirkin and directed to systems and methods for managing processor overcommit for virtual machines.
U.S. Pub. No. 2006/0069835 A1 to Arackai et al. and directed to a method is provided of managing hardware triggered hotplug operations of one or more input/output (I/O) cards of a computer system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights