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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The rejection under 35 U.S.C 112 have been withdrawn in view of applicant’s amendments and remarks.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3, 8 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over by Saito (US 20130081016 A1) in view of Apfelbaum (US 12141611 B2).
Regarding claim 1, Saito teaches:
A method comprising: (Claim 22. A control method for controlling a virtual machine system, the virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of:)
in response to receiving, at a simultaneous multithreading (SMT) processor, a request to execute a first virtual machine, identifying whether a first thread is executing at a first logical thread of the SMT processor, wherein the first thread is associated with first software different than the first virtual machine; and ([0095] FIG. 4 is a functional structure diagram showing the main functional blocks constituting the virtual machine system 100, in a state where three virtual machines are allocated to the processor A 101 and one virtual machine is allocated to the processor C 103.[0096] As shown in FIG. 4, the virtual machine system 100 includes a hypervisor 440 and a plurality of virtual machines (virtual machines A 411, B 412, C 413, and D 414 in the present example). [0149] Upon completion of step S730, the virtual machine allocation unit 442 causes all the virtual machines to operate on the processor A 101, based on the virtual machine information stored in the virtual machine information storage unit 445 (step S740). [0152] The system update processing is processing of dynamically changing the attribute of each processor, based on a change in the number of tasks existing in each task queue managed by the OS operating in each virtual machine, and dynamically changing the allocation of the virtual machines to the processors. [0402] The allocation unit 3501 allocates each virtual machine to any processor that is supplied with power. For example, the allocation unit 3501 is realized as one of the functions of the hypervisor 440 in Embodiment 1 (see FIG. 4).) ([0163] If the number of tasks is equal to or greater than the first predetermined number (such as 30) in step S910, the virtual machine allocation unit 442 checks whether another virtual machine is allocated to, and operating on, the processor on which the virtual machine identified by the selected virtual machine ID is operating (step S920) . [0164] If another virtual machine is allocated to and operating on the processor in step S920 (step S920: Yes), the virtual machine allocation unit 442 checks whether a processor having the attribute of "standby" exists (step S930). [0168] When the virtual machine allocation change processing is started by the virtual machine system 100, the virtual machine allocation unit 442 checks whether a target virtual machine in the moving source processor is performing processing (step S1100) [0381] (9) According to Embodiment 1, when a processor causes a plurality of virtual machines to operate, the processor repeatedly and sequentially causes the virtual machines to operate by time sharing. However, the processor may use a method other than time sharing, as long as the processor can cause the plurality of virtual machines to operate. For example, the processor may have a multithread processing function which enables parallel execution of a plurality of threads, and may cause the plurality of virtual machines to operate in parallel, with use of the multithread processing function.. EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
Saito does not appear to explicitly teach: in response to identifying that the first thread is executing at the first logical thread, preventing execution of the first virtual machine on a second logical thread of the SMT processor responsive to security control information indicating that SMT protection is enabled for the first virtual machine.
However, Apfelbaum teaches: col 10, line 41-44. At block 330, method 300 involves preventing simultaneous allocation of the processor core to the workload and the other workload based on the processor policy being a second policy or a third policy. Col 11, line 12-31 The third policy could be a policy that attempts to maximize the number of processor cores reserved for the workload by reserving a separate processor core for each single thread of the requested processor threads of the workload (even if the reserved processor core(s) is capable of SMT execution of multiple threads simultaneously). Referring back to FIG. 2 for example, in a scenario where the number of requested processor threads of the workload (e.g., indicated by the message received at block 310) is three processor threads and the processor policy of the workload is the third policy, the CPU manager 214 may reserve a different core 222 for each of the three requested processor threads of the workload (e.g., core 222A for a first thread, core 222B for a second thread, and core 222C for a third thread). Thus, in this example, each of the reserved processor cores allocated to the workload may have an unallocated virtual core; and the CPU manager 214 may continue preventing any allocation to those unallocated virtual cores while the workload is allocated to their physical processor cores under the third policy. See also col 9, line 64 -col 10, line 15.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Saito and Apfelbaum before them, to modify Saitos’s virtual machine execution system, Saito expressly suggested multithread processing (Saito [0381]) using Apfelbaum’s SMT aware processor sharing policy. One would have been motivated to prevent or allow simultaneous execution of different workloads on sibling logical threads based on workload security policy. Thereby reducing the risk of data leakage between workloads while preserving the performance benefits of SMT, as taught by Apfelbaum (col 3, line 20-43)
Regarding claim 2, Apfelbaum teaches:
The method of claim 1, further comprising: in response to identifying that the first thread is idle at the first logical thread, allowing execution of the first virtual machine on the second logical thread regardless of whether the SMT protection is enabled or disabled. (col 10, line 20-40. The first policy could be a policy that attempts to minimize an overall cost of running the workload on a node by allowing SMT execution of the workload with other workloads on a same processor core. For instance, even though SMT execution of different workloads on a same processor core may expose them to the risk of data leakage in a high-level cache (e.g., one of caches 222A-D) of the processor core, the first policy may attempt to optimize an overall cost of running the workload while accepting the data leakage risk. Referring back to FIG. 2 for example, each of the requested processor threads of the workload can be assigned by CPU manager 214 to any available virtual core 224 when the processor policy of the workload is the first policy (even if other virtual core(s) of the same processor core are executing other workloads). Additionally, CPU manager 214 may allow subsequent allocations of any processor core 222 that is currently executing one or more of the processor threads of the workload (and which has an available virtual core 224) to one or more other workloads for SMT execution. E.N.: under the first policy, corresponding to protection disable execution on the second logical thread is allowed )
Regarding claim 3, Apfelbaum teaches:
The method of claim 1,further comprising: in response to identifying that the first thread is executing at the first logical thread, allowing execution of the first virtual machine on the second logical thread responsive to security control information indicating that SMT protection is disabled for the first virtual machine. (col 10, line 20-40. The first policy could be a policy that attempts to minimize an overall cost of running the workload on a node by allowing SMT execution of the workload with other workloads on a same processor core. For instance, even though SMT execution of different workloads on a same processor core may expose them to the risk of data leakage in a high-level cache (e.g., one of caches 222A-D) of the processor core, the first policy may attempt to optimize an overall cost of running the workload while accepting the data leakage risk. Referring back to FIG. 2 for example, each of the requested processor threads of the workload can be assigned by CPU manager 214 to any available virtual core 224 when the processor policy of the workload is the first policy (even if other virtual core(s) of the same processor core are executing other workloads). Additionally, CPU manager 214 may allow subsequent allocations of any processor core 222 that is currently executing one or more of the processor threads of the workload (and which has an available virtual core 224) to one or more other workloads for SMT execution. E.N.: under the first policy, corresponding to protection disable execution on the second logical thread is allowed )
Regarding claim 8, Saito teaches:
A method, comprising: (Claim 22. 22. A control method for controlling a virtual machine system, the virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of: )
in response to receiving, at a simultaneous multithreading (SMT) processor an interrupt associated with first software while a first thread of the first software is in an idle state at a first logical thread of the SMT processor: ([0152] The system update processing is processing of dynamically changing the attribute of each processor, based on a change in the number of tasks existing in each task queue managed by the OS operating in each virtual machine, and dynamically changing the allocation of the virtual machines to the processors. [0165] If a processor having the attribute of "standby" exists in step S930 (step S930: Yes), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "standby" to "exclusive" (step S940). [0166] Upon completion of step S940, the virtual machine allocation unit 442 changes the processor to which the virtual machine identified by the selected virtual machine ID is allocated to operate, from the processor to which the virtual machine is currently allocated to operate (hereinafter "moving source processor") to the processor whose attribute has been changed from "standby" to "exclusive" in step S940 (hereinafter "moving destination processor") (step S950: virtual machine allocation change processing). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
Saito does not appear to explicitly teach: responsive to determining that a first virtual machine is executing at a second logical thread of the SMT processor, preventing the first thread from executing at the first logical thread responsive to the interrupt.
However, Apfelbaum teaches: col 10, line 41-44. At block 330, method 300 involves preventing simultaneous allocation of the processor core to the workload and the other workload based on the processor policy being a second policy or a third policy. Col 11, line 12-31 The third policy could be a policy that attempts to maximize the number of processor cores reserved for the workload by reserving a separate processor core for each single thread of the requested processor threads of the workload (even if the reserved processor core(s) is capable of SMT execution of multiple threads simultaneously). Referring back to FIG. 2 for example, in a scenario where the number of requested processor threads of the workload (e.g., indicated by the message received at block 310) is three processor threads and the processor policy of the workload is the third policy, the CPU manager 214 may reserve a different core 222 for each of the three requested processor threads of the workload (e.g., core 222A for a first thread, core 222B for a second thread, and core 222C for a third thread). Thus, in this example, each of the reserved processor cores allocated to the workload may have an unallocated virtual core; and the CPU manager 214 may continue preventing any allocation to those unallocated virtual cores while the workload is allocated to their physical processor cores under the third policy. See also col 9, line 64 -col 10, line 15.
Same motivation as claim 1.
Regarding claim 12, Saito teaches:
The method of claim 8, wherein preventing the first thread from executing comprises preventing the first thread from executing at the first logical thread responsive to an SMT protection mode being enabled for the first virtual machine. ([0123] Each of the attributes 602 is information indicating the attribute of a processor identified by a corresponding processor ID. [0124] Each of the processors A 101 to D 104 is associated with one of four attributes, i.e., "exclusive", "share", "standby", and "off". [0125] The attribute of "exclusive" indicates that the processor operates in the normal operation mode in which the supply voltage is 1.2 V and the operating frequency is 1 GHz, and the number of virtual machines operating on the processor is limited to one. [0178] If another virtual machine is not allocated to the processor to operate in step S920 (step S920: No), the virtual machine allocation unit 442 causes the processor management unit 444 to update the processor information stored in the processor information storage unit 446, such that the attribute of the processor is changed from "share" to "exclusive" (step S990). [0179] If the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is not "share" in step S900, i.e., the attribute of the processor is "exclusive" (step S900: No), the virtual machine allocation unit 442 checks whether the number of tasks corresponding to the virtual machine is equal to or less than a second predetermined number (such as 25) (step S1000 of FIG. 10). EN: Figures 4, 15, 22, 34 clearly show a task, e.g. thread can execute on certain VMs. The prior art demonstrates that incoming VMs are either allowed or disallowed to run on a particular processor that is already running a VM having tasks, i.e. threads, based on the mode set by the processor.)
Regarding claim 13, Saito teaches:
The method of claim 12, further comprising executing the first thread at the first logical thread responsive to the SMT protection mode being disabled for the first virtual machine. ([0161] After selecting one virtual machine ID, the virtual machine allocation unit 442 reads (i) the virtual machine information stored in the virtual machine information storage unit 445 and (ii) the processor information stored in the processor information storage unit 446, and checks whether the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" (step S900). [0162] If the attribute of the processor on which the virtual machine identified by the selected virtual machine ID is operating is "share" in step S900 (step S900: Yes), the virtual machine allocation unit 442 checks whether the number of tasks corresponding to the virtual machine is equal to or greater than a first predetermined number (such as 30) (step S910). [0163] If the number of tasks is equal to or greater than the first predetermined number (such as 30) in step S910, the virtual machine allocation unit 442 checks whether another virtual machine is allocated to, and operating on, the processor on which the virtual machine identified by the selected virtual machine ID is operating (step S920).)
Regarding claim 14, Saito teaches:
A simultaneous multithreading (SMT) processor comprising: a processor core to receive a request to execute a first virtual machine; and secure hardware to. (Claim 12. A virtual machine system including a plurality of processors and for causing a plurality of virtual machines to operate, each processor being placed in any of: )
The claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale
Regarding claim 15, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Claims 4-7, 9-11 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saito (US 20130081016 A1) in view of Apfelbaum (US 12141611 B2) and further view of Tsirkin (US 11106481 B2).
Regarding claim 4, Saito does not appear to explicitly teach:
The method of claim 2, further comprising: subsequent to allowing execution of the first virtual machine on the second logical thread, in response to receiving an interrupt associated with the first software while the first thread is in an idle state at the first logical thread and the first virtual machine is executing at the second logical thread: preventing the first thread from executing at the first logical thread responsive to the interrupt..
However, Tsirkin teaches: (col 6, line 51-67. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A. Once logical processor 202-B has returned control to hypervisor 235 (e.g., the logical processor has been halted), logical processor management module 243 can then send an instruction to logical processor 202-A to transfer execution control to hypervisor 235. In some implementations, logical processor management module 243 may determine that logical processor 202-B has returned control to hypervisor 235 by receiving a notification from logical processor 202-B that it has returned control.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Saito and Tsirkin before them, to include Tsirkin’s interrupt feature Saito’s virtual machine management system. Incorporating Tsirkin’s teaching would merely involve applying a known technique of interrupt based execution control to a virtual machine management framework yielding predictable result of preventing execution of thread or virtual processors while handling interrupts .
Regarding claim 5, Tsirkin teaches:
The method of claim 4, further comprising: in response to receiving the interrupt while the first thread is in an idle state and the first virtual machine is executing: notifying the first virtual machine of the interrupt; and exiting execution of the first virtual machine from the second logical thread in response to the notifying. (col 8, line37-52. At block 305, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block 310, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block 315, processing logic determines an execution state of the second virtual processor. In some implementations, processing logic makes this determination by receiving a notification from the second virtual processor that the second virtual processor has executed a VM exit to return control to the hypervisor. At block 320, processing logic determines whether the execution state of the second virtual processor indicates that it is running. If so, processing proceeds to block 325. If so, processing continues to block 325. Otherwise, processing proceeds to block 335.)
Same motivation as claim 4
Regarding claim 6, Tsirkin teaches:
The method of claim 5, wherein notifying the first virtual machine comprises triggering an inter-processor interrupt (IPI) to the first virtual machine. (col 6, line 44-58. Responsive to virtual processor management module 242 determining that the execution state of virtual processor 231-B indicates that it is running, logical processor management module 243 may be invoked to send an instruction to logical processor 202-B (the logical processor associated with virtual processor 231-B) to cause the virtual processor 202-B to return control to hypervisor 235. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A.)
Same motivation as claim 4
Regarding claim 7, Tsirkin teaches:
The method of claim 6, wherein notifying the first virtual machine comprises writing a specified value to a register to trigger the IPI. (col 7, line 60-67. As noted above, this instruction could be an IPI instruction. Alternatively, logical processor management module 243 may set an indicator that prevents the hypervisor from executing a hypervisor related task using logical processor 202-A. In some implementations, this indicator may be stored in a register, data structure, memory space, or other similar structure, that is checked by hypervisor 235 prior to executing a hypervisor related task.)
Same motivation as claim 4
Regarding claim 9, Tsirkin teaches:
The method of claim 8, further comprising: in response to receiving the interrupt while the first thread is in the idle state at the first logical thread and the first virtual machine is executing at the second logical thread: notifying the first virtual machine of the interrupt; and exiting execution of the first virtual machine from the second logical thread in response to the notifying. (col 8, line37-52. At block 305, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block 310, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block 315, processing logic determines an execution state of the second virtual processor. In some implementations, processing logic makes this determination by receiving a notification from the second virtual processor that the second virtual processor has executed a VM exit to return control to the hypervisor. At block 320, processing logic determines whether the execution state of the second virtual processor indicates that it is running. If so, processing proceeds to block 325. If so, processing continues to block 325. Otherwise, processing proceeds to block 335.)
Same motivation as claim 4
Regarding claim 10, Tsirkin teaches:
The method of claim 9, wherein notifying the first virtual machine comprises triggering an inter-processor interrupt (IPI) to the first virtual machine. (col 6, line 44-58. Responsive to virtual processor management module 242 determining that the execution state of virtual processor 231-B indicates that it is running, logical processor management module 243 may be invoked to send an instruction to logical processor 202-B (the logical processor associated with virtual processor 231-B) to cause the virtual processor 202-B to return control to hypervisor 235. In some implementations, logical processor management module 243 may send an inter-processor interrupt (IPI) to logical processor 202-B by invoking interrupt processing module 244. The IPI can cause logical processor 202-B to cause virtual processor 231-B to return control to the hypervisor 235. Thus, virtual processor 231-B should not execute a VM related task while hypervisor 235 retains execution control of logical processor 202-A.)
Same motivation as claim 4
Regarding claim 11, Tsirkin teaches:
The method of claim 10, wherein notifying the first virtual machine comprises writing a specified value to a register to trigger the IPI. (col 7, line 60-67. As noted above, this instruction could be an IPI instruction. Alternatively, logical processor management module 243 may set an indicator that prevents the hypervisor from executing a hypervisor related task using logical processor 202-A. In some implementations, this indicator may be stored in a register, data structure, memory space, or other similar structure, that is checked by hypervisor 235 prior to executing a hypervisor related task.)
Same motivation as claim 4
Regarding claim 17, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Bradbury (US 9354883 B2) – Teaches selectively enabling or preventing SMT execution by controlling whether multiple hardware threads execute on a processor core.
Mall (US 20070300227 A1) – Teaches restricting execution to a selected hardware thread while requiring sibling hardware threads to remain idle in an SMT enable processor.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights