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-4,6-9,12-16 and 19-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.
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-4, 8-9, 12, 15-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ionescu (US 20210026950 A1) in view of Lutas (US 20180173555 A1).
Regarding claim 1, Ionescu teaches:
A method comprising. (Claim 1. A computer-implemented method comprising:)
generating a user space processing thread in an idle state, wherein the user space processing thread runs in a user space that is segregated from a kernel space; ([0031] The computing device may implement multiple protection rings or privilege levels which provide different levels of access to system resources. For example, user-level 104 may be at an “outer” ring or level, with the least access (e.g., “ring 3”), kernel-level 102 may be at an “inner” ring or level, with greater access (e.g., “ring 0” or “ring 1”), and hypervisor-level 112 may be an “inner-most” ring or level (e.g., “ring −1” or “ring 0”), with greater access than kernel-level 102. Any component at the hypervisor-level 112 may be a hypervisor which sits “below” (and has greater access than) a host OS kernel 106.)
detecting, by an exception handler of a virtual machine running on a host computer system, a request to execute a privileged instruction in the user space by the virtual machine. ([0071] In another example, the receipt of a system call by the security agent 108 may trigger another type of security action at 168. For instance, the security agent 108, prior to receipt of the system call, may be configured to monitor the creation (and destruction) of processes 118(1)-(N) (collectively 118) on the host computing device by observing process creation events associated with user-level processes 118. In a similar manner, the creation (and destruction) of threads can be monitored on the host computing device by observing thread creation events associated with threads. Accordingly, FIG. 1e shows that processes 118(1)-(N) or threads may be associated with corresponding tokens 174(1)-(N) (collectively 174) in the kernel mode 102. The individual tokens 174 may include privilege information that indicates a privilege with which a corresponding process 118 or a corresponding thread is allowed to execute. For example, a first token 174(1) associated with a corresponding first user-level process 118(1) or a thread may indicate that the first user-level process 118(1) or the thread is allowed to execute with an Administrator (“Admin”) privilege, which may be a greater privilege than say a “Guest” privilege. Thus, a second token 174(2) associated with a corresponding second user-level process 118(2) or a thread may indicate that the second user-level process 118(2) or the thread is allowed to execute with a comparatively lower “Guest” privilege, but not an Admin privilege. Thus, the privilege information (e.g., indications of Admin, Guest, and other types of privileges) in the tokens 174 may indicate what level of access a corresponding user-level process 118 or thread has to resources and components on the system. In the running example, the first user-level process 118(1) or thread executes with greater privilege than the second user-level process 118(2) or thread, and therefore, the first user-level process 118(1) or thread has access to resources and/or components on the system that the second user-level process 118(2) or thread may not be allowed to access.)
signaling, by enabling a bit flag in the memory associated with the virtual machine, a request to execute the privileged instruction by the user space processing thread running on the host computer system. ([0074] Other events may trigger the security agent 108 to initiate a security action at 168 that determines whether values of any of the kernel-level tokens 174 have changed from an original token value to an updated token value. For instance, a context switch between one thread and another thread may be detected through changes in another processor MSR 160 (or through changes in another register, such as a GS register), and this context switch may act as a trigger event to have the security agent 108 check for a change of a token 174 value.[0075] It is also to be appreciated that a MSR 160 is merely one kind of processor configuration register whose value can be changed at 158 of FIG. 1e. Thus, a similar technique to that described with reference to FIG. 1e can be utilized with any type of processor configuration register, such as a different type of processor configuration register in place of the MSR 160.)
causing the user space processing thread to wake up from the idle state. ([0071] For instance, the security agent 108, prior to receipt of the system call, may be configured to monitor the creation (and destruction) of processes 118(1)-(N) (collectively 118) on the host computing device by observing process creation events associated with user-level processes 118. In a similar manner, the creation (and destruction) of threads can be monitored on the host computing device by observing thread creation events associated with threads. Accordingly, FIG. 1e shows that processes 118(1)-(N) or threads may be associated with corresponding tokens 174(1)-(N) (collectively 174) in the kernel mode 102.)
and signaling, by disabling the bit flag, that the privileged instruction has been processed. ([0080] This instruction may be in the form of an “interrupt exiting” flag instruction, or a similar instruction, which allows a hypervisor component to generate an interrupt and have it kept in a pending state until the host OS kernel 106 is able to receive interrupts. Without such an instruction, the interrupt generated at 182 may get lost (i.e., not received by the host OS kernel 106 or the interrupt handler 176 of the security agent 108) if and when the host OS kernel 106 clears or disables interrupts, such as by executing a “clear interrupt” (CLI) flag instruction, for example. That is, when the host OS kernel 106 doesn't want to have its processing blocked, the host OS kernel 106 may execute clear or disable interrupts (e.g., via a CLI instruction) to make sure no interrupts come in, and, at a subsequent time, the host OS kernel 106 may execute a “set interrupt” (STI) flag instruction to receive all interrupts that are pending.)
Ionescu does not appear to explicitly teach: storing at least a part of a state of the virtual machine in a memory associated with the virtual machine; and pausing execution of the virtual machine;
However, Lutas teaches: [0031] In some embodiments, processor 12 may store a part of a VMSO within dedicated internal registers/caches, while other parts of the respective VMSO may reside in memory 18. At any given time, at most one VMSO (herein termed the current VMSO) may be loaded onto a logical processor, identifying the virtual machine currently having control of the respective logical processor. When processor 12 switches from executing a first VM to executing a second VM or hypervisor 30, processor 12 may save the current state of the first VM to the guest state area of the current VMSO. [0037] In particular, execution of some processor instructions requires the privilege level of hypervisor 30 (e.g., VMXroot). Examples of such instructions include VMCALL on Intel® platforms. In some hardware systems, invoking such an instruction from within a virtual machine generates a particular type of fault known as a virtual machine exit event (e.g., VMExit on Intel® platforms). VM exit events suspend the execution of the respective virtual machine and switch processor 12 to executing a handler routine outside the respective VM, typically at the processor privilege level of hypervisor 30.[0038] In some hardware platforms, VM exits may be triggered by other types of events, such as a violation of a memory access permission. In one such example, when a software object executing within a VM attempts to write data to a memory page marked as non-writable, or to execute code from a memory page marked as non-executable, processor 12 may generate a page fault, and in response, suspend execution of the respective VM, and switch to executing hypervisor 30. Such exit mechanisms may allow, for example, a computer security program executing outside the respective VM (such as introspection engine 40) to protect the virtual machine against security threats. In some embodiments, introspection engine 40 intercepts VM exit events occurring during execution of software inside the VM and further analyzes such events, potentially without the knowledge of in-VM software. In case the event is indicative of an attack, engine 40 may take several threat-mitigating actions, such as suspending execution of the respective guest VM, cutting off communications to and/or from the respective guest VM, injecting a cleanup agent into the respective guest VM, alerting a user of host system 10, etc.
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 Ionescu and Lutas before them, to include Lutas’s VM-exit suspension method in Ionescu’s hypervisor based interception and handling of protected operations. One would have been motivated to make such a combination to more reliable preserve the execution context of the virtual machine while the operation is being process and later resume the virtual machine as taught by Lutas.
Regarding claim 2, Lutas teaches:
The method of claim 1, further comprising: responsive to receiving, from the user space processing thread, a notification that the privileged instruction was performed, resuming, by the exception handler, execution of the virtual machine. ([0033] In some embodiments, a plurality of security components collaborate to protect guest VMs 32a-b against computer security threats such as malicious software. FIG. 2 illustrates such security components as a set of event filters 42a-b executing within guest VMs 32a-b, respectively, and an introspection engine 40 executing outside guest VMs 32a-b. Introspection engine 40 may further include a notification handler 44. In some embodiments, each event filter 42a-b detects the occurrence of certain events during execution of software within the respective guest VM.)
Regarding claim 3, Ionescu teaches:
The method of claim 2, wherein the notification comprises an interrupt. ([0080] At 182, in response to noting the access operation at 178, and in response to determining to offload one or more tasks to the security agent 108 at 180, the security agent component 110 may generate an interrupt that is received by the host OS kernel 106. The interrupt generated by the security agent component 110 may be similar to the way that other hardware device interrupts are generated on the host computing device for actual hardware devices, such as the keyboard, the mouse, and the like. However, because the security agent component 110 is not an actual hardware device, but acts as a hardware device (e.g., a virtual hardware device), the security agent component 110 may be configured to execute an instruction that, upon execution, places the interrupt in a queue as a pending interrupt. This instruction may be in the form of an “interrupt exiting” flag instruction, or a similar instruction, which allows a hypervisor component to generate an interrupt and have it kept in a pending state until the host OS kernel 106 is able to receive interrupts. Without such an instruction, the interrupt generated at 182 may get lost (i.e., not received by the host OS kernel 106 or the interrupt handler 176 of the security agent 108) if and when the host OS kernel 106 clears or disables interrupts, such as by executing a “clear interrupt” (CLI) flag instruction, for example. That is, when the host OS kernel 106 doesn't want to have its processing blocked, the host OS kernel 106 may execute clear or disable interrupts (e.g., via a CLI instruction) to make sure no interrupts come in, and, at a subsequent time, the host OS kernel 106 may execute a “set interrupt” (STI) flag instruction to receive all interrupts that are pending. This does not present an issue with interrupts generated by actual hardware devices because those interrupts stay pending after they are generated, ensuring that the host OS kernel 106 will receive them when interrupts are allowed. The security agent component 110 may mimic this behavior by executing a particular instruction to have its own interrupts treated as pending interrupts until the host OS kernel 106 executes an STI instruction, for example, allowing receipt of any pending interrupts thereafter. See also [0081] and [0158-0164])
Regarding claim 4, Lutas teaches:
The method of claim 1, further comprising: responsive to determining that the bit flag has been disabled, resuming, by the exception handler, execution of the virtual machine. ([0060] In some embodiments, event filter 42 selectively notifies introspection engine 40 about the occurrence of a subset of trigger events considered relevant for security. Events may be selected according to a set of eligibility criteria, and only events deemed eligible may be communicated to introspection engine 40. In response to detecting the occurrence of a trigger event which is not considered eligible for communicating to introspection engine 40, some embodiments employ emulator 47 to emulate the detected event (step 444 in FIG. 7). Subsequently, filter 42 may signal to processor 12 to resume execution of guest software within the respective VM, without triggering a VM exit. When an event satisfies the eligibility criteria, in a step 442 some embodiments generate a VM exit event, thus notifying introspection engine 40 of the occurrence of the respective trigger event. Generating the VM exit event may comprise, for instance, filter 42 issuing a privileged processor instruction, such as VMCALL on Intel® platforms. To communicate event parameters to engine 40, some embodiments of event filter 42 write the respective parameters to a section of memory shared between filter 42 and introspection engine 40, before generating the VM exit even)
Regarding claim 8, Ionescu teaches:
A method, comprising. (Claim 1. A computer-implemented method comprising)
generating a first user space processing thread in an idle state, wherein the first user space processing thread is in a user space that is segregated from a kernel space; ([0065] FIG. 1e illustrates an overview of a security agent component initiated as a hypervisor of a computing device, the security agent component being configured to redirect system calls to the security agent, intercept read operations from a process, thread, or component different from a processor that are directed to a processor configuration register, such as a Model Specific Register (MSR) of the processor, and respond to the read operations with a permitted result. As illustrated, at 158, the security agent component 110 (executing as a hypervisor of a computing device) may change a value of a MSR 160 of a processor 124 of the computing device from an original MSR value to an updated MSR value. This may be done when the host computing device first loads (e.g., boots up). At 162, the security agent component 110 may set an intercept for instructions for performing read operations on the MSR 160. Setting an intercept at 162 may include setting an intercept for non-processor entities (e.g., processes, threads, or components different from the processor 124) who are attempting to read the value of the MSR 160. In other words, after setting the intercept at 162, instructions for performing MSR 160 read operations from entities different from the processor 124 are intercepted, while instructions for performing MSR 160 read operations from the processor 124 are not intercepted. Thus, the processor 124 will read the updated MSR value at 164, causing system calls to be redirected to the security agent 108 at 166, thereby allowing the security agent 108 to initiate a security action at 168 in response to receiving a system call. See also [0064-0071])
monitoring, by a second user space processing thread running on a host computer system, a memory location of a memory associated with a virtual machine running on the host computer system. ([0038] Memory 120 may be memory of any sort of memory device. As shown in FIG. 1a, memory 120 may include multiple memory locations 122, the number of memory locations 122 varying based on the size of memory 120. The memory locations 122 may be addressed through addresses of memory pages and offsets, with each memory page including one or more memory locations. Privileges associated with memory locations 122, such as reading, writing, and executing may be set on a per-page granularity, with each memory page having a privilege attribute. Thus, memory locations 122 of a same page may have the same privileges associated with them. Examples of memory 120 are illustrated in FIG. 3 and described below in detail with reference to that figure. [0071] In another example, the receipt of a system call by the security agent 108 may trigger another type of security action at 168. For instance, the security agent 108, prior to receipt of the system call, may be configured to monitor the creation (and destruction) of processes 118(1)-(N) (collectively 118) on the host computing device by observing process creation events associated with user-level processes 118. In a similar manner, the creation (and destruction) of threads can be monitored on the host computing device by observing thread creation events associated with threads. Accordingly, FIG. 1e shows that processes 118(1)-(N) or threads may be associated with corresponding tokens 174(1)-(N) (collectively 174) in the kernel mode )
responsive to detecting that a bit flag has been enabled at the memory location, executing a privileged instruction in the user space on behalf of the virtual machine; causing the first user space processing thread to wake up from the idle state; detecting that the bit flag has been disabled; ([0080] At 182, in response to noting the access operation at 178, and in response to determining to offload one or more tasks to the security agent 108 at 180, the security agent component 110 may generate an interrupt that is received by the host OS kernel 106. The interrupt generated by the security agent component 110 may be similar to the way that other hardware device interrupts are generated on the host computing device for actual hardware devices, such as the keyboard, the mouse, and the like. However, because the security agent component 110 is not an actual hardware device, but acts as a hardware device (e.g., a virtual hardware device), the security agent component 110 may be configured to execute an instruction that, upon execution, places the interrupt in a queue as a pending interrupt. This instruction may be in the form of an “interrupt exiting” flag instruction, or a similar instruction, which allows a hypervisor component to generate an interrupt and have it kept in a pending state until the host OS kernel 106 is able to receive interrupts. Without such an instruction, the interrupt generated at 182 may get lost (i.e., not received by the host OS kernel 106 or the interrupt handler 176 of the security agent 108) if and when the host OS kernel 106 clears or disables interrupts, such as by executing a “clear interrupt” (CLI) flag instruction, for example. That is, when the host OS kernel 106 doesn't want to have its processing blocked, the host OS kernel 106 may execute clear or disable interrupts (e.g., via a CLI instruction) to make sure no interrupts come in, and, at a subsequent time, the host OS kernel 106 may execute a “set interrupt” (STI) flag instruction to receive all interrupts that are pending. This does not present an issue with interrupts generated by actual hardware devices because those interrupts stay pending after they are generated, ensuring that the host OS kernel 106 will receive them when interrupts are allowed. The security agent component 110 may mimic this behavior by executing a particular instruction to have its own interrupts treated as pending interrupts until the host OS kernel 106 executes an STI instruction, for example, allowing receipt of any pending interrupts thereafter.)
Ionescu does not appear to explicitly teach: responsive to detecting that the bit flag has been disabled, sending a notification to the virtual machine that the privileged instruction was executed.
However, Lutas teaches: [0046] In some embodiments, eligibility checker 46 is configured to filter events that triggered virtualization exceptions, to produce a subset of events considered malware-indicative or in other ways relevant to computer security. Exemplary security-relevant events may include, for instance, an attempt to overwrite a field of a page table entry, an attempt to execute a critical OS component such as a memory allocation function, an attempt to read, write, or execute code to/from a specific memory section, etc. Notification generator 48 may be configured to notify introspection engine 40 about the occurrence of the selected subset of events produced by eligibility checker 46. The notification mechanism may employ any method known in the art of hardware virtualization, such as triggering a VM exit event via a privileged processor instruction such as VMCALL. Notification generator 48 may transmit data, such as details or parameters of the notified events, to introspection engine 40 for instance by writing the respective data to a predetermined section of memory shared between filter 42 and engine 40.
Same motivation as claim 1.
Regarding claim 9, Lutas teaches:
The method of The method of wherein the first user space processing thread and the second user space processing thread are associated with a same central processing unit (CPU). ([0030] Each VMSO may comprise data representing a current state of a respective virtualized processor exposed on host system 10. In multithreading configurations, hardware processor 12 may operate a plurality of cores, each core further comprising multiple logical processors, wherein each logical processor may process an execution thread independently of, and concurrently with, other logical processors. Multiple logical processors may share some hardware resources, for instance, a common MMU. In a multithreaded embodiment, a distinct VMSO may be set up for each distinct logical processor. The respective VMSO may comprise a guest state area and a host state area, the guest state area holding the CPU state of the respective VM, and the host state area storing the current state of hypervisor 30. In some embodiments, the guest-state area of the VMSO includes contents of the control registers (e.g., CR0, CR3, etc.), instruction pointer (e.g., RIP), general-purpose registers (e.g., EAX, ECX, etc.), and status registers (e.g., EFLAGS) of the virtual processor of the respective VM, among others. The host state area of the VMSO may include a pointer (e.g., an EPT pointer on Intel® platforms) to a page table configured for address translations for the respective VM.)
Regarding claim 12, Lutas teaches:
The method of claim 8, further comprising: extracting the privileged instruction from state data stored in the memory associated with the virtual machine. ([0030] Each VMSO may comprise data representing a current state of a respective virtualized processor exposed on host system 10. In multithreading configurations, hardware processor 12 may operate a plurality of cores, each core further comprising multiple logical processors, wherein each logical processor may process an execution thread independently of, and concurrently with, other logical processors. Multiple logical processors may share some hardware resources, for instance, a common MMU. In a multithreaded embodiment, a distinct VMSO may be set up for each distinct logical processor. The respective VMSO may comprise a guest state area and a host state area, the guest state area holding the CPU state of the respective VM, and the host state area storing the current state of hypervisor 30. In some embodiments, the guest-state area of the VMSO includes contents of the control registers (e.g., CR0, CR3, etc.), instruction pointer (e.g., RIP), general-purpose registers (e.g., EAX, ECX, etc.), and status registers (e.g., EFLAGS) of the virtual processor of the respective VM, among others. The host state area of the VMSO may include a pointer (e.g., an EPT pointer on Intel® platforms) to a page table configured for address translations for the respective VM.[0031] In some embodiments, processor 12 may store a part of a VMSO within dedicated internal registers/caches, while other parts of the respective VMSO may reside in memory 18. At any given time, at most one VMSO (herein termed the current VMSO) may be loaded onto a logical processor, identifying the virtual machine currently having control of the respective logical processor. When processor 12 switches from executing a first VM to executing a second VM or hypervisor 30, processor 12 may save the current state of the first VM to the guest state area of the current VMSO.)
Regarding claim 15, Ionescu teaches:
A system, comprising. (Claim 16. A system comprising: a processor; a memory coupled to the processor; a security agent configured to be operated by the processor to).
The claim recites similar limitation as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale
Regarding claim 16, the claim recites similar limitation as corresponding claim 9 and is rejected for similar reasons as claim 9 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 12 and is rejected for similar reasons as claim 12 using similar teachings and rationale.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ionescu (US 20210026950 A1) in view of Lutas (US 20180173555 A1) and in further view of Eidus (US 20130145363 A1).
Regarding claim 6, Ionescu does not appear to explicitly teach:
The method of claim 1, wherein the user space processing thread implements a user space hypervisor.
However, Eidus teaches: (Claim 1. An apparatus operating in a para-virtualized environment, comprising: a processor; and a memory coupled to the processor and configured to store at least a first set of instructions for a first hypervisor for execution by the processor and a second set of instructions for a second hypervisor for execution by the processor over the first hypervisor, wherein the first hypervisor is configured to enable execution of an unmodified guest program over the second hypervisor and wherein the unmodified guest program and the second hypervisor operate in a user space protection domain. [0020] Operating generally as a hypervisor, the IHV 230 is modified to capture a set of privileged instructions that require execution in Ring 0 (kernel) of the computing device. The set of privileged instructions may be preconfigured with the IHV 230 and additional instructions may be added as needed. For example, a new version release of the IHV 230 may include additional privileged instructions. In one embodiment, the set of instructions is defined based on the type of the PVHV 120, a list of features supported by the PVHV 120, and so on. The IHV 230 may be also configured to bridge the gap to allow compatibility of other software resources of the unmodified guest 240 and the PVHV 120.)
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 Ionescu and Eidus before them, to include Eidus’s interface hypervisor operating in a user space domain in Ionescu’s hypervisor based interception and handling of protected operations. One would have been motivated to make such a combination to allow the system to handle privileged instructions request thought a user space hypervisor as taught by Eidus.
Regarding claim 14, Eidus teaches:
The method of claim 8, wherein the second user space processing thread implements a user space hypervisor. (Claim 1. An apparatus operating in a para-virtualized environment, comprising: a processor; and a memory coupled to the processor and configured to store at least a first set of instructions for a first hypervisor for execution by the processor and a second set of instructions for a second hypervisor for execution by the processor over the first hypervisor, wherein the first hypervisor is configured to enable execution of an unmodified guest program over the second hypervisor and wherein the unmodified guest program and the second hypervisor operate in a user space protection domain. [0020] Operating generally as a hypervisor, the IHV 230 is modified to capture a set of privileged instructions that require execution in Ring 0 (kernel) of the computing device. The set of privileged instructions may be preconfigured with the IHV 230 and additional instructions may be added as needed. For example, a new version release of the IHV 230 may include additional privileged instructions. In one embodiment, the set of instructions is defined based on the type of the PVHV 120, a list of features supported by the PVHV 120, and so on. The IHV 230 may be also configured to bridge the gap to allow compatibility of other software resources of the unmodified guest 240 and the PVHV 120.)
Same motivation as claim 6.
Claims 7, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ionescu (US 20210026950 A1) in view of Lutas (US 20180173555 A1) and in further view of view Tsirkin (US 20200341792 A1).
Regarding claim 7, Ionescu does not appear to explicitly teach:
The method of claim 1, wherein pausing execution of the virtual machine comprises performing at least one of a MWAIT instruction, a polling instruction, or a halt instruction.
However, Tsirkin teaches: However, Tsirkin teaches: ([0035] While in the guest execution mode, each vCPU may perform memory monitoring (e.g., using x86-64 MONITOR/MWAIT instructions, their analogs on other execution platforms, or other memory access instructions) in order to receive notifications of newly arriving IPIs. In one implementation, in order to enable memory monitoring by vCPUs, the hypervisor 180 may configure the VMCS of VM170A to allow the virtual machine to execute MONITOR/MWAIT instructions (or other memory access instructions) without causing a VM exit. Also [0021] and [0048])
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 Ionescu and Tsirkin before them, to include Tsirkin’s execution of execute MONITOR/MWAIT instructions in Ionescu’s hypervisor based interception and handling of protected operations. One would have been motivated to make such a combination to improve the system efficiency by allowing the allowing the hypervisor to handle requests more effectively without causing excessive overhead or interruptions.
Regarding claim 13, Tsirkin teaches:
The method of claim 8, wherein monitoring the predefined memory location comprises executing at least one of a UMONITOR instruction or a UMWAIT instruction. ([0035] While in the guest execution mode, each vCPU may perform memory monitoring (e.g., using x86-64 MONITOR/MWAIT instructions, their analogs on other execution platforms, or other memory access instructions) in order to receive notifications of newly arriving IPIs. In one implementation, in order to enable memory monitoring by vCPUs, the hypervisor 180 may configure the VMCS of VM170A to allow the virtual machine to execute MONITOR/MWAIT instructions (or other memory access instructions) without causing a VM exit. Also [0021] and [0048])
Same motivation as claim 7
Regarding claim 20, the claim recites similar limitation as corresponding claim 13 and is rejected for similar reasons as claim 13 using similar teachings and rationale.
Conclusion
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