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 .
Claim Objections
Claims 2, 9, and 16 are objected to because of the following informalities:
Claims 2, 9, 16 discloses “wherein the opcode of the instruction is to indicate is a virtual machine function instruction” (line 3), however, it is recommended that this is revised to “wherein the opcode of the instruction indicates a virtual machine function instruction.”
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6-11, and 13-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tsai (US 2017/0206177, hereinafter Tsai).
Regarding claim 1, Tsai discloses
An apparatus comprising:
decoder circuitry (paragraph [0028]: Instruction unit 320 may include any circuitry, logic, structures, and/or other hardware, such as an instruction decoder) to decode a single instruction, the single instruction to include a field for an opcode (paragraph [0028]: Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330); and
execution processing resources to execute the decoded single instruction according to the at least the opcode (paragraph [0028]: Instruction unit 320 may include any circuitry, logic, structures, and/or other hardware, such as an instruction decoder, to fetch, receive, decode, interpret, schedule, and/or handle instructions (including inter-VM-IPI instruction 322, described below) to be executed by processor 300. Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330) to cause an exitless guest to host notification (paragraph [0062]: a sending VM may send a notification/interrupt to a target VM without a VM exit and without invoking a VMM … the notify-processor for the target processor in the target VM may, in response to a notify event, send an IPI by writing to the Interrupt Command Register of the corresponding vAPIC page (e.g., vAPIC page 23) with a vector corresponding to an inter-VM-IPI. If the target VM is active, the notification/interrupt may be delivered directly to the target VM (without a VM exit or invoking VMM) and without invoking a VMM. If the target VM is scheduled, the notification/interrupt may be posted (without a VM exit or invoking VMM) from a virtual processor to a physical or virtual processor (paragraph [0051]: the present invention provide for an inter-VM-IPI to be sent from guest software being executed by a first virtual processor in any VM (e.g., the first VM) to a second virtual processor in any other VM (e.g., the second VM) regardless of whether the first virtual processor and the second virtual processor are abstracted from the same physical processor or physical processor core or from two physical processors or physical processor cores in/on the same or different integrated circuits, die, chips, substrates, or packages).
Regarding 8 referring to claim 1, Tsai discloses A method comprising: … (See the rejection for claim 1).
Regarding claim 15, Tsai discloses
A method comprising:
translating a single instruction from a first instruction set architecture into one or more instructions of a second instruction set architecture, the single instruction to include a field for an opcode; decoding the one or more instructions of the second instruction set architecture (paragraph [0028]: Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330); and
processing the decoded single instruction according to the at least the opcode (paragraph [0028]: Instruction unit 320 may include any circuitry, logic, structures, and/or other hardware, such as an instruction decoder, to fetch, receive, decode, interpret, schedule, and/or handle instructions (including inter-VM-IPI instruction 322, described below) to be executed by processor 300. Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330) to cause an exitless guest to host notification notification (paragraph [0062]: a sending VM may send a notification/interrupt to a target VM without a VM exit and without invoking a VMM … the notify-processor for the target processor in the target VM may, in response to a notify event, send an IPI by writing to the Interrupt Command Register of the corresponding vAPIC page (e.g., vAPIC page 23) with a vector corresponding to an inter-VM-IPI. If the target VM is active, the notification/interrupt may be delivered directly to the target VM (without a VM exit or invoking VMM) and without invoking a VMM. If the target VM is scheduled, the notification/interrupt may be posted (without a VM exit or invoking VMM) from a virtual processor to a physical or virtual processor (paragraph [0051]: the present invention provide for an inter-VM-IPI to be sent from guest software being executed by a first virtual processor in any VM (e.g., the first VM) to a second virtual processor in any other VM (e.g., the second VM) regardless of whether the first virtual processor and the second virtual processor are abstracted from the same physical processor or physical processor core or from two physical processors or physical processor cores in/on the same or different integrated circuits, die, chips, substrates, or packages).
Regarding claim 18, Tsai discloses
system comprising:
a first processor core (paragraph [0051]: two physical processor cores) including:
decoder circuitry (paragraph [0028]: Instruction unit 320 may include any circuitry, logic, structures, and/or other hardware, such as an instruction decoder) to decode a single instruction, the single instruction to include a field for an opcode (paragraph [0028]: Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330); and
execution processing resources to execute the decoded single instruction according to the at least the opcode (paragraph [0028]: Instruction unit 320 may include any circuitry, logic, structures, and/or other hardware, such as an instruction decoder, to fetch, receive, decode, interpret, schedule, and/or handle instructions (including inter-VM-IPI instruction 322, described below) to be executed by processor 300. Any instruction format may be used within the scope of the present invention; for example, an instruction may include an opcode and one or more operands, where the opcode may be decoded into one or more micro-instructions or micro-operations for execution by execution unit 330) to cause an exitless guest to host notification (paragraph [0062]: a sending VM may send a notification/interrupt to a target VM without a VM exit and without invoking a VMM … the notify-processor for the target processor in the target VM may, in response to a notify event, send an IPI by writing to the Interrupt Command Register of the corresponding vAPIC page (e.g., vAPIC page 23) with a vector corresponding to an inter-VM-IPI. If the target VM is active, the notification/interrupt may be delivered directly to the target VM (without a VM exit or invoking VMM) and without invoking a VMM. If the target VM is scheduled, the notification/interrupt may be posted (without a VM exit or invoking VMM) from a virtual processor to a second processor core (paragraph [0051]: the present invention provide for an inter-VM-IPI to be sent from guest software being executed by a first virtual processor in any VM (e.g., the first VM) to a second virtual processor in any other VM (e.g., the second VM) regardless of whether the first virtual processor and the second virtual processor are abstracted from the same physical processor or physical processor core or from two physical processors or physical processor cores in/on the same or different integrated circuits, die, chips, substrates, or packages);
memory coupled to the processor core to store the single instruction (paragraph [0021]: system memory space 200 may contain VM control structure (VMCS) 210 corresponding to a sending VM, inter-VM-IPI instruction 212 in guest software 214 to be executed by the sending VM, inter-VM-IPI table 220 (including entry 222 having handle field 224, posted-interrupt descriptor (PID) address field 226, and vector field 228), virtual local Advanced Programmable Interrupt Controller (APIC) page 230, PID 240, and VMCS 250 (including virtual local APIC (vAPIC) pointer 252 and PID pointer 254) corresponding to a target VM, all of which are defined and/or described below; paragraph [0051]: two physical processor cores).
Regarding claims 2, 9, and 16, Tsai discloses
wherein the opcode of the instruction is to indicate is a virtual machine function instruction and an implicit register value is to indicate exitless guest to host notification (paragraph [0038]: A first parameter associated with the VMFUNC instruction (e.g., the value in the EAX register in a processor in the Intel® Core® Processor Family) may specify that the function to be invoked is an inter-VM-IPI function (for example, the value of ‘1’ in the EAX register may specify the inter-VM-IPI function, which may therefore be referred to as VMFUNC(1)); paragraph [0062]: a sending VM may send a notification/interrupt to a target VM without a VM exit and without invoking a VMM … the notify-processor for the target processor in the target VM may, in response to a notify event, send an IPI by writing to the Interrupt Command Register of the corresponding vAPIC page (e.g., vAPIC page 23) with a vector corresponding to an inter-VM-IPI. If the target VM is active, the notification/interrupt may be delivered directly to the target VM (without a VM exit or invoking VMM) and without invoking a VMM. If the target VM is scheduled, the notification/interrupt may be posted (without a VM exit or invoking VMM) from a virtual processor to a physical or virtual processor (paragraph [0051]: the present invention provide for an inter-VM-IPI to be sent from guest software being executed by a first virtual processor in any VM (e.g., the first VM) to a second virtual processor in any other VM (e.g., the second VM) regardless of whether the first virtual processor and the second virtual processor are abstracted from the same physical processor or physical processor core or from two physical processors or physical processor cores in/on the same or different integrated circuits, die, chips, substrates, or packages).
Regarding claim 3, 10, 17, and 19, Tsai discloses
wherein the execution processing resources, in response to the decoded single instruction, are further to index an inter-virtual machine inter-processor interrupt (IVIT) data structure using an index to acquire a destination identifier from an entry of the IVIT data structure (paragraph [0044]: Software, such as a VMM, may allocate a PID for each virtual processor that may be the target of an inter-VM-IPI. Each PID may have a format 400 as illustrated in FIG. 4, including fields 410, 420, 430, and 440; paragraph [0047]: Sub-field 422 (Dest-ID) may include 32 bits to identify the destination of the interrupt request, which, for example, may be the local APIC for the physical processor on which the virtual processor that is the target of the interrupt request is running), set a vector value in a posted-interrupt requests field of the destination (paragraph [0045]: [0045] Field 410 may include the lowest 32 bytes of a 64-byte PID to form a 256-bit posted interrupt request register (pIRR). Each bit of the pIRR may correspond to one of 256 virtual interrupt vectors for the virtual processor corresponding to the PID. Each bit of the pIRR may be set to post an interrupt request for a corresponding virtual interrupt vector (e.g., the virtual interrupt vector specified by vector field 228)).
Regarding claim 4 and 11, Tsai discloses
wherein the destination identifier is an address of a posted interrupt descriptor (FIGURE 4 Posted-Interrupt Descriptor 400; paragraph [0047]: Sub-field 422 (Dest-ID) may include 32 bits to identify the destination of the interrupt request).
Regarding claims 6 and 13, Tsai discloses
wherein an index is to be provided by a field of the instruction (paragraph [0042]: handle field 224 may include 16 bits to store a handle value to be used to as an entry number, address, index, pointer, or other locator of or to a particular entry in the table such that a handle value specified by an inter-VM-IPI instruction may be used by inter-VM-IPI lookup circuitry 332 to find the desired entry in the table).
Regarding claims 7 and 14, Tsai discloses
wherein the inter-processor interrupt is to be sent to an programmable interrupt controller (paragraph [0031]: local interrupt controller 350 may be a local APIC in a processor in the Core® Processor Family from Intel Corporation; paragraph [0047]: Sub-field 422 (Dest-ID) may include 32 bits to identify the destination of the interrupt request, which, for example, may be the local APIC for the physical processor on which the virtual processor that is the target of the interrupt request is running).
Regarding claim 20, Tsai discloses
wherein the inter-processor interrupt is to be sent to an programmable interrupt controller (paragraph [0031]: local interrupt controller 350 may be a local APIC in a processor in the Core® Processor Family from Intel Corporation; paragraph [0047]: Sub-field 422 (Dest-ID) may include 32 bits to identify the destination of the interrupt request, which, for example, may be the local APIC for the physical processor on which the virtual processor that is the target of the interrupt request is running) of the second processor core (paragraph [0051]: the present invention provide for an inter-VM-IPI to be sent from guest software being executed by a first virtual processor in any VM (e.g., the first VM) to a second virtual processor in any other VM (e.g., the second VM) regardless of whether the first virtual processor and the second virtual processor are abstracted from the same physical processor or physical processor core or from two physical processors or physical processor cores in/on the same or different integrated circuits, die, chips, substrates, or packages) .
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 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 of this title, 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 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Tsai (US 2017/0206177, hereinafter Tsai) in view of Pan et al. (US 2019/0213153 hereinafter Pan).
Regarding claim 5 and 12, Tsai discloses
wherein the destination identifier is an address of a … posted interrupt descriptor (FIGURE 4 Posted-Interrupt Descriptor 400; paragraph [0047]: Sub-field 422 (Dest-ID) may include 32 bits to identify the destination of the interrupt request).
Tsai does not disclose a user posted interrupt descriptor. Pan discloses a user posted interrupt descriptor (paragraph [0025]: the interrupt data 2845 may be implemented as a user posted interrupt descriptor (UPID). The interrupt data 2845 may indicate destination handlers and/or processing engines for all user interrupts associated with a particular task; paragraph [0311]: The UPID may also include a Notification Vector field to identify the notification vector. The UPID may also include a Notification Destination field to identify the notification destination. In some embodiments, the notification destination may be specified as a target physical Advanced Programmable Interrupt Controller (APIC) identifier. The UPID may also include a Posted Interrupt Requests field to indicate whether there is a user interrupt request for a user vector).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Tsai’s PID including sub-field (Dest-ID) to identify the destination of the interrupt request by Pan’s a user posted interrupt descriptor (UPID) including Notification Destination field to identify the notification destination, thereby resulting in UPID including destination id to identify the destination of the interrupt request for all user interrupt. The motivation would have been to reduce the time required to process the user interrupt and provide improved performance of interrupt handling (Pan paragraph [0345]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Tsirkin (US 2018/0150311) discloses “a hypervisor 160 may grant a VM 170A or guest OS 190A access to a VM Function 192A to allow the VM 170A or guest OS 190A to access a resource without requiring an exit to the hypervisor 160. In an example, the hypervisor 160 may also deny the request by causing an undefined opcode exception or a general protection fault exception whenever the VM Function 192A is invoked” (paragraph [0030]).
Wang et al. (US 2017/0262306) discloses “the decoder parses the instruction into an opcode and corresponding data and control fields that are used by the micro-architecture” (paragraph [0085]) and “FIG. 13 schematically illustrates using EPTP switching VM function (e.g., VMFUNC 0) for enabling a virtual machine to perform certain privileged operations without exiting to the VMM (e.g., to access a host memory allocated to a peer virtual machine for exit-less communications with the peer virtual machine)” (paragraph [0106]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 01/30/2026