DETAILED ACTION
Claims 1-20 are pending.
Priority: 4/30/2020(FP)
Assignee: Intel
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 Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
1.Claims 1,8,15 are rejected for reciting a limitation with antecedent basis issues.
Claim 1 recites, ‘wherein the data mover device is to access the data from the source data buffer….using the first PASID and is to copy the data to the destination data buffer….using the second PASID based on….’.
As recited, ‘the first PASID’ and ‘the second PASID’ have not been previously introduced. Furthermore, though ‘source PASID’ and ‘destination PASID’ are equivalent to ‘the first PASID’ and ‘the second PASID’ respectively, referring to the same variable using two different variables, in the same claim, does not recite a clear antecedent basis and makes the recitation ambiguous.
1.Claim 1 is rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Claim 1 recites, ‘a copy operation indicated by a descriptor stored in a descriptor queue in a first address space’, and further recites, ‘the copy operation to copy data from a source address space…. ….a first VM…. to a destination address space….a second VM’.
Though spec, Para-0102 recites that ‘a first address space’ is associated with ‘a source address space’, the claim does not recite it. However, since claim 1 refers to the same variable using two different variables (e.g. ‘source address space’ initially and then ‘first address space’), the recitation is ambiguous. Because the claim is open to multiple interpretations, the metes and bounds are rendered indefinite. Hence claim 1 is rejected.
2.Claims 2,9,16 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 2 recites, ‘wherein the descriptor includes one or more fields to indicate a corresponding one or more permissions tables from which to determine the first PASID and the second PASID’.
Nowhere does the spec recite this limitation.
Para-0021 of the spec recites, ‘To verify an access requested by a first agent to an address space of a second agent is permitted, the data mover may include or be coupled to a PASID permissions table (PPT). This permissions table….validate…access permissions for accessing the other PASIDs,….limiting access to certain address ranges’.
As shown, the spec recites only one ‘permissions table’. Therefore, the recitation, ‘a corresponding one or more permissions tables’, being unclear, is indefinite and leads to uncertainty about the claim scope. Hence claim 2 is rejected. Claims 9,16 have the same issue.
3.Claims 5,12,19 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 5 recites, ‘wherein the descriptor comprises a first Input/output (IO) work descriptor and the descriptor queue comprises a first descriptor queue, wherein a first virtual device…….is to access a second IO work descriptor…., process the second IO work descriptor, prepare the first IO work descriptor from the second IO work descriptor, …..queue’.
The spec does not recite this limitation.
That said, the limitation is indefinite. Because the independent claim recites ‘a descriptor’ and ‘a descriptor queue’, it is unclear whether ‘the descriptor’ and ‘the descriptor queue’ are referring to the same ones from the independent claim, or if the dependent claim is improperly trying to introduce new descriptors and queues.
Since the limitation recites, ‘the descriptor comprises…’, suggesting adding new elements, dependent claim 5 is broadening the scope of independent claim 1, which is not permitted.
The recitation, ‘the descriptor queue comprises a first descriptor queue’, implies that the descriptor queue is composed of another descriptor queue. In computer architecture, this is structurally incorrect (a queue usually stores descriptors, not other queues).
The claim 5 limitation does not align with Paras:0082-0085 of the spec.
The limitation is also indefinite because it does not align with Fig. 9 of the spec. Based on claim 1 and Fig. 9, step 910, the recitation ‘the descriptor comprises a first Input/output (IO) work descriptor’ is ambiguous because the first IO work descriptor (‘descriptor’ in claim 1) is already prepared by the guest driver and stored in the descriptor queue in the first address space of the first VM.
Furthermore, the recitation, ‘access a second IO work descriptor from a second descriptor queue’, is unclear based on Para-0080, Fig. 9, step 930.
Since the ‘second IO work descriptor’ is an arbitrary descriptor, it is unclear what ‘process the second IO work descriptor’ means.
Therefore the limitation, ‘prepare the first IO work descriptor from the second IO work descriptor’ does not clearly define the metes and bounds of the claim. The recitation overwrites the information already present in the prepared first I/O work descriptor, thereby lending uncertainty to the copy operation and reciting an indefinite claim scope. The overwriting of an already prepared descriptor is inconsistent with the spec.
The claim improperly pieces together limitations from separate paragraphs of the spec. When read in light of the spec, the claim fails to inform the true scope and boundaries of the disclosure. Hence claim 5 is rejected. Claims 12,19 have the same issue.
4.Claims 7,14,20 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 7 recites, ‘wherein the first ADI is to access an interrupt table stored in the address space accessible to the second VM using a third PASID’.
The spec does not recite this limitation.
Para-0077 of the spec recites, ‘….a scalable IOV device may store….(MSI) interrupt messages in a table (e.g., an interrupt table) in host memory. The interrupt table may be created in a separate address space than descriptor queues and data buffers. Consequently, the ADIs may use a third PASID to fetch the MSI message from the interrupt table for generating an interrupt to notify (e.g., requester and/or target) as to completion of descriptors’.
As shown, the spec does not recite that the interrupt table is stored in the address space accessible to the second VM. The spec recites that the interrupt table is stored in host memory.
It is well-known that host memory comprises of physical address space, virtual address space (includes user space), kernel space, I/O address space, heap, stack, PCIe address space etc.
More importantly, claim 1 recites that the first ADI is associated with the first VM and the abstract recites, ‘each of the plurality of ADIs is to be associated with one of the plurality of VMs’.
Therefore how the first ADI can access or be associated with an address space accessible to the second VM, is unclear, hence indefinite. Accordingly, claim 7 is rejected. Claims 14,20 have the same issue.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Claims 1,3, are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘data mover device comprising: a plurality of assignable device interfaces (ADIs), including a first ADI associated with the first VM and a second ADI associated with the second VM’.
The spec does not recite this limitation.
Para-0003 of the spec recites, ‘A data mover is a device/accelerator that offloads memory copy and other related operations from a processor’. The spec does not disclose where the data mover device is located.
Para-0004 of the spec recites, ‘Many computing systems also provide support for scalable….(IOV) devices. These devices, ….define assignable device interfaces (ADIs) that can be assigned to a ….(VM) as ….(VDEV) emulation…..’
According to the spec Figs. 7-8, ‘a first ADI’ and ‘a second ADI’ are included in the scalable IOV (not the data mover device).
The spec clearly discloses that the data mover device (Figs. 1,6) and the scalable IOV device (Figs. 8,9) are two separate devices, with distinct functions. There is no written description support in the spec or the figures to show that the two devices are integrated/coupled. There is no written description support (figures included) to show that their functions are mingled, as recited in claim 1. There is no written description support for the data mover device to comprise a plurality of ADIs, including ‘a first ADI’ and ‘a second ADI’. There is no written description support to show that the data mover device comprises ‘circuitry to fetch the descriptor from the descriptor queue’.
Since the ADIs are shown in Figs. 7-8 of the spec, the spec does not explicitly disclose which computing unit is the ‘data mover device’ in the systems shown in Figs. 7-8 of the spec. In other words, the data mover device is a ‘black box’.
More importantly, the lack of written description support clearly describing how the data mover device integrates with the scalable IOV device and other claimed elements (VMs, VMM, smart controller etc.), and how the data mover device ‘comprises’ the ADIs, demonstrates lack of possession by the inventor at the time of filing.
Accordingly claim 1 recites a limitation with a scope unsupported by the spec, thereby reciting new matter. Hence claim 1 is rejected. Claims 8, 15 have the same issues.
2.Claim 1,8,15 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘a copy operation indicated by a descriptor, the copy operation to copy data from a source address space corresponding to a source ….PASID associated with a first …VM to a destination address space corresponding to a destination PASID associated with a second VM’.
The spec recites this limitation, but a one-line recitation does not fulfill the written description requirement.
Though the definition of PASID is well-known, the spec does not disclose how the ‘source PASID’ and the ‘destination PASID’ are generated, so that their values can be used to populate the descriptor to perform the copy operation by the data mover device.
In other words, the claim is directed to a result (copying data from source to destination) without describing the necessary steps, e.g., specific algorithm, working examples, or specific configurations, to show the inventor was in possession of the claimed limitation at the time of filing, that achieve that result. Simply stating the function to be performed is not sufficient to satisfy the written description requirement.
Hence claim 1 is rejected for reciting a limitation that lacks written description support in the spec. Claims 8,15 have the same issue.
3.Claims 2,9,16 are rejected for reciting a limitation that is unsupported by the spec.
Claim 2 recites, ‘wherein the descriptor includes one or more fields to indicate a corresponding one or more permissions tables from which to determine the first PASID and the second PASID’.
Fig. 2 of the spec discloses that the fields are ‘destination PASID selector’ and ‘source PASID selector’.
That said, Para-0021 of the spec recites, ‘To verify an access…., the data mover may include or be coupled to a PASID permissions table (PPT)’. Since the data mover device lacks structure, location and integration, the spec leaves the device at a purely conceptual level which shows that the inventor was not in possession of the data mover device interacting with the table, at the time of filing. This suggests that the table is not enabled.
Para-0032 of the spec further recites, ‘the PASID permissions table (PPT) translates a PASID selector in a job descriptor to an access PASID and its access permissions. The PASID selector is used as an index into the PPT’.
But the spec does not disclose how the PASID selector is generated, how it is ‘translated’ for each PASID, how the ‘index’ is represented, and how the index is used to search the pre-populated table.
In other words, the claim recites a scope that exceeds what is enabled.
The spec fails to support the scope of the claim, making the claim encompass subject matter not described. Hence claim 2 is rejected because the spec does not provide written description support for searching and using the pre-populated table to determine the first PASID and the second PASID via the PASID selector fields. Claims 9,16 have the same issue.
4.Claims 3,10,17 are rejected for reciting a limitation that is unsupported by the spec.
Claim 3 recites, ‘wherein the data mover device is to use the first ADI to access the data from the source data buffer and is to use the second ADI to store the data in the destination data buffer’.
Nowhere does the spec recite this limitation.
Para-0082 of the spec recites, ‘an IOV device including: …..and a plurality of ADIs coupled to the at least one function circuit, where each of the plurality of ADIs is to be associated with one of the plurality of VMs….’. The spec does not disclose that the data mover device is the scalable IOV device or the scalable IOV device is the data mover device.
The spec discloses that the data mover device and the scalable IOV device are two distinct devices.
Though the data mover device’s function is to copy data, there is no disclosure about how it physically integrates with other claimed elements such as the VMs, VMM, scalable IOV device, the ADIs, smart controller etc., shown in Figs. 7-8 of the spec. Copying data from one VM to another is well-known, but how the data mover device accomplishes it by integrating with the components in Figs. 7-8 of the spec, lacks written description support.
Since the spec discloses that data mover device does not include the ADIs, how it uses the first ADI and the second ADI to access the source VM data buffer and destination VM data buffer, as recited in claim 3, lacks written description support in the spec, demonstrating lack of possession. Hence claim 3 recites a limitation that is unsupported by the spec and is rejected for reciting new matter. Claims 10,17 have the same issue.
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, 3-8, 10-15, 17-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Sankaran et al (WO2018125250A1) in view of Deval et al (20190114283).
As per Claim 1, Sankaran discloses an apparatus (Sankaran, [0039 - A data streaming accelerator/DSA device comprising multiple work queues which receive descriptors submitted over an I/O fabric interface]; [0034 - Fig. 30 includes an accelerator and one or more computer processor chips coupled to the processor over a multi-protocol link]), comprising:
- one or more cores to execute instructions (Sankaran, [0073 – In Fig. 69 an accelerator is communicatively coupled to a plurality of cores through a cache coherent interface]);
- a memory controller to couple the one or more cores to a system memory (Sankaran, [0215 - In Fig. 119, memory controller 11900 couples the cores and/or accelerator(s) 11917 to memory]);
- a data mover device coupled to the memory controller (Sankaran, [0412 - In Fig. 30, coherence controllers 3009 conditionally issue memory access messages to the accelerator's memory controller 3006 over the multi-protocol link 2800]) to perform a copy operation indicated by a descriptor (Sankaran, [0630 - Fig. 43 shows a memory move descriptor 4300 and memory move completion record 4301]; [0055 - Fig. 51 shows a memory copy with dual cast descriptor and memory copy with dual cast completion record]) stored in a descriptor queue (Sankaran, [0473 - Fig. 35 shows a DSA device comprising multiple work/descriptors queues 3511-3512 which receive descriptors submitted over IO fabric interface 3501]) in a first address space (Sankaran, [1436 - At least one client of the plurality of clients comprises a user-mode application or container executed within a VM]; [0371 - PASID tags specify the addresses to be translated as belonging to the virtual address space of a specific process]; [0503 – Fig. 38: source address field 3805]),
- the copy operation to copy data (Sankaran, [0630 - Fig. 43 shows a memory move descriptor 4300 and memory move completion record 4301. The Memory Move operation 4308 copies memory from the Source Address 4302 to the Destination Address 4303]) from a source address space corresponding to a source ([See 112(a)]) process address space identifier (PASID) (Sankaran, [0390 - software configures the PASID capability to control whether the device uses PASID to perform address translation. If PASID is enabled, virtual or physical addresses may be used, depending on IOMMU configuration]) associated with a first virtual machine (VM) (Sankaran, [0630 - Fig. 43: Source Address 4302]) to a destination address space corresponding to a destination PASID associated with a second VM (Sankaran, [0630 - Fig. 43: Destination Address 4303]; [0488 - Clients/applications are identified by the device using a 20-bit ID called PASID. The PASID is used by the device to look up addresses in the Device TLB 1722 and to send address translation or page requests to the IOMMU 1710]),
- the data mover device (Sankaran, [Fig. 30 - accelerator 3001]) comprising:
- a plurality of assignable device interfaces (ADIs) (Sankaran, [0746 - Devices supporting SR-IOV may support independent SWQs for each Virtual Function/VF, exposed through SWQ_REGs in respective VF base address registers/BARs]),
- circuitry to fetch the descriptor from the descriptor queue (Sankaran, [Figs. 34-35]; [0437 - Work Queues/WQ hold descriptors submitted by software]; [0437 - Dedicated work queues 3400 store descriptors for a single application 3413 while shared work queues 3401 store descriptors submitted by multiple applications 3410-3412. A hardware interface/arbiter 3402 dispatches descriptors from the work queues 3400-3401 to the accelerator processing engines 3405]),
- the descriptor (Sankaran, [0630 - Fig. 43 shows a memory move descriptor 4300]) to indicate the copy operation (Sankaran, [Fig. 43: Memory Move operation field 4308]; [0630 – In Fig. 43, memory Move operation 4308 copies memory from the Source Address 4302 to the Destination Address 4303]), a source data buffer in the source address space (Sankaran, [0516 - For operations that read data from memory, the source address field 3805 specifies the address of the source data]), and a destination data buffer in the destination address space (Sankaran, [0516 – In Fig. 38, for operations that write/copy data to memory, the destination address field 3806 specifies the address of the destination buffer]),
- wherein the data mover device is to access the data from the source data buffer in the source address space using the first PASID (Sankaran, [0488 - In shared mode, the PASID to be used with each descriptor is contained in the PASID/first field of the descriptor]) and is to copy the data to the destination data buffer in the destination address space using the second PASID (Sankaran, [0388 – Table A : Addresses are translated using the PASID in the descriptor]) based on the descriptor fetched from the descriptor queue (Sankaran, [Figs. 34-35]; [0160 - A hardware interface/arbiter dispatches descriptors from the work/descriptor queues to the accelerator processing engines in accordance with a specified arbitration policy]).
Deval further clarifies the ADIs as follows,
- the data mover device (Deval, [0023 - SR-IOV is supported by multiple high performance I/O devices such as reconfigurable devices such as GPUs, FPGAs and other accelerators]) comprising:
- a plurality of assignable device interfaces (ADIs) (Deval, [Fig. 5: ADIs 520, 522, 524, 526]), including a first ADI associated with the first VM (Deval, [Fig. 5: Guest Partition 502 – ADI 520]) and a second ADI associated with the second VM (Deval, [Fig. 5: Guest Partition 504 – ADI 524]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the ADIs of Deval into the DSA of Sankaran for the benefit of VMMs making use of platform support for DMA and interrupt remapping capability to support ‘direct device assignment’ allowing guest software to directly access the assigned device. This direct device assignment provides the best I/O virtualization performance since the VMM is no longer in the way of most guest software accesses to the device (Deval, 0022).
As per Claim 3, the rejection of claim 1 is incorporated, and Sankaran, Deval disclose,
- wherein the data mover device ([See 112(a)]) is to use the first ADI (Deval, [Fig. 5: Guest Partition 502 – ADI 520]) to access the data from the source data buffer and is to use the second ADI (Deval, [Fig. 5: Guest Partition 504 – ADI 524]) to store the data in the destination data buffer (Deval, [0126 – In Fig. 11, at step 1104, guest driver 424 creates a packet descriptor in the guest VM for a packet to be transmitted]; [0127 – In Fig. 12, at step 1210, host driver 412 provides the modified packet descriptor to the transmit queue in PF 232/ADI. At step 1212, IOMMU 414 translates address of the packet buffer based at least in part on PASID 1 806 and the packet descriptor based at least in part on PASID 2 804 to a host physical address. At step 1214, physical function/PF 232 transmits the packet from the transmit queue]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the ADIs of Deval into the DSA of Sankaran for the benefit of VMMs making use of platform support for DMA and interrupt remapping capability to support ‘direct device assignment’ allowing guest software to directly access the assigned device. This direct device assignment provides the best I/O virtualization performance since the VMM is no longer in the way of most guest software accesses to the device (Deval, 0022).
As per Claim 4, the rejection of claim 1 is incorporated, and Sankaran, Deval disclose,
- wherein the first address space (Deval, [Fig. 5: Guest Partition 502 – ADI 522]) is associated with a third PASID (Deval, [Fig. 5]; [0084 - If ADIs belonging to a virtual device/VDEV assigned to a VM are further mapped to application processes within the VM, each such ADI is assigned a unique PASID corresponding to the secondary address domain. This enables usages such as Shared Virtual Memory/SVM within a VM, thereby implying that the first address space can have multiple PASIDs]), the circuitry to fetch the descriptor with the third PASID (Deval, [0082 - Requests from ADIs are distinguished through a Process Address Space Identifier/PASID in an end-to-end PASID TLP Prefix]; [0081 - virtual device 1 508 calls ADI 2 522 via fast path direct mapping 540]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the address translation functions of Deval into the DSA of Sankaran for the benefit of scalable IOVs enabling unique address translation functions for upstream requests at PASID granularity. Unlike RID, PASID is not used for transaction routing on the I/O fabric but instead is used only to convey the address space targeted by a memory transaction. Also, PASIDs are 20-bit IDs compared to 16-bit RIDs, which gives 16× more identifiers. This use of PASIDs by the Scalable IOVs enables significantly more domains to be supported by Scalable IOV devices (Deval, 0049).
As per Claim 5, the rejection of claim 1 is incorporated, and Sankaran discloses,
- wherein the descriptor comprises a first ([See 112(b)]) Input/output (IO) work descriptor (Sankaran, [Fig. 35: an individual work descriptor 3514]) and the descriptor queue comprises a first descriptor queue (Sankaran, [Fig. 35: WQ 3512]; [0473 - Multiple work/descriptor queues 3511-3512 receive descriptors submitted over an I/O fabric interface 3501]),
Deval discloses,
- wherein a first virtual device provided by a smart controller (Deval, [0052 – In Fig. 4, Virtual Device Composition Module/VDCM 402 is responsible for composing one or more virtual device/VDEV 404 instances utilizing one or more Assignable Device Interfaces/ADIs 406, 408, which the VDCM does by emulating VDEV slow path operations/accesses and mapping the VDEV fast path accesses to ADI instances allocated and configured on the physical device]), in response to a request (Deval, [0123 – In Fig. 8, packets are used to receive data from a component external to PF 232 for forwarding to guest VM 422]), is to access a second IO work descriptor from a second descriptor queue (Deval, [Fig. 8]),
- process the second IO work descriptor (Deval, [0123 – In Fig. 8, packet descriptor D1 808 in queue 802 has a first/second packet descriptor format specific to PF 232 and is referenced by an address in host address space. IOMMU with scalable IOV extensions 414 translates the host physical address of packet descriptor D1 808 based at least in part on PASID 2 804 so that host driver 412 can access packet descriptor D1 808]; [Also see Fig. 12]),
- prepare the first IO work descriptor ([See 112(b)]) from the second IO work descriptor (Deval, [0123 - Host driver 412 includes a modifier 820 to modify the format of packet descriptor D1 808, translating the packet descriptor D1 808/second into packet descriptor D1-1 822/first. Host driver 412 modifies the format of the packet descriptor but does not modify data in the packet descriptor; Here the modification implies using the second packet descriptor to prepare the first packet descriptor. This modification is the same as Fig. 9 of the spec]; [Also see Fig. 12]),
- and store the first IO work descriptor in the first descriptor queue (Dewal, [0123 – In Fig. 8, host driver 412 sends the modified packet descriptor D1-1 822 to guest driver 424 in guest VM 422. This involves a copying of the small packet descriptor from host driver 412 to guest driver 424, thereby implying that due to the copy, the first IO work descriptor is stored in the first descriptor queue in host memory space]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the ADIs of Deval into the DSA of Sankaran for the benefit of VMMs making use of platform support for DMA and interrupt remapping capability to support ‘direct device assignment’ allowing guest software to directly access the assigned device. This direct device assignment provides the best I/O virtualization performance since the VMM is no longer in the way of most guest software accesses to the device (Deval, 0022).
As per Claim 6, the rejection of claim 1 is incorporated, and Sankaran, Deval disclose,
- an input/output (IO) memory management unit (IOMMU) (Deval, [Fig. 4: IOMMU 414]) to receive a first virtual address from the first ADI including the first PASID (Deval, [0082 - Requests from ADIs are distinguished through a Process Address Space Identifier/PASID in an end-to-end PASID TLP Prefix]) and send a first physical address corresponding to the first virtual address (Deval, [0062 - VDCM 402 may request VMM 180 to set up GPA to HPA mappings in the host processor 122-1 . . . 122-M virtualization page tables, enabling direct access by guest driver 424 to the ADI. These direct mapped MMIO ranges support fast path operations 426 to ADIs 432, 434]) to the first ADI (Deval, [Figs. 4-5]) to enable the access to the first data buffer (Deval, [0125 - In Fig. 10, step 1014, IOMMU 414 translates the address of the packet buffer included in the modified packet descriptor based at least in part on PASID 1 806 from guest virtual address space to host physical address space]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the address translation of Deval into the DSA of Sankaran for the benefit of having the address translation function programmed for PASIDs representing host SVM usage refers to respective CPU virtual address to physical address translation, while the address translation function programmed for PASIDs representing guest SVM usage refers to respective nested address, .i.e. guest virtual address to guest physical address and further to host physical address translation (Deval, 0032).
As per Claim 7, the rejection of claim 1 is incorporated, and Sankaran, Deval disclose,
- wherein the first ADI ([See 112(b)]) is to access an interrupt table (Deval, [0066 - ADI generated interrupts use interrupt messages stored in Interrupt Message Storage/IMS 328]; [0092 - Specific host OS 150/VMM 180 implementations support the use of IMS 328 for PF's interrupts and/or the use of PF's MSI-X table for ADI interrupts]) stored in the address space accessible to the second VM using a third PASID (Deval, [0084 - An ADI is configured to access meta-data, commands and completions with one PASID/third PASID that represents a restricted control domain/address space while the data accesses are associated with the PASID of the domain to which the ADI is assigned]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the IMS of Deval into the DSA of Sankaran for the benefit of using scalable IOV devices as they include PF BARs, which include many ADI MMIO components. PF BARS are coupled with PF config, PF MSI-X, and interrupt message storage/IMS for ADIs. IMS enables devices to store the interrupt messages for ADIs in a device-specific optimized manner (Deval, 0046).
As per Claim 8, it is similar to claim 1 and therefore the same mappings are incorporated.
As per Claim 10, it is similar to claim 3 and therefore the same mappings are incorporated.
As per Claim 11, it is similar to claim 4 and therefore the same mappings are incorporated.
As per Claim 12, it is similar to claim 5 and therefore the same mappings are incorporated.
As per Claim 13, it is similar to claim 6 and therefore the same mappings are incorporated.
As per Claim 14, it is similar to claim 7 and therefore the same mappings are incorporated.
As per Claim 15, it is similar to claim 1 and therefore the same mappings are incorporated.
As per Claim 17, it is similar to claim 3 and therefore the same mappings are incorporated.
As per Claim 18, it is similar to claim 4 and therefore the same mappings are incorporated.
As per Claim 19, it is similar to claim 5 and therefore the same mappings are incorporated.
As per Claim 20, it is similar to claim 7 and therefore the same mappings are incorporated.
Claims 2, 9, 16 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Sankaran et al (WO2018125250A1) in view of Deval et al (20190114283) and Kumar et al (WO2018152688A1).
As per Claim 2, the rejection of claim 1 is incorporated, and Sankaran discloses,
wherein the descriptor includes one or more fields (Sankaran, [0476 - The work queue configuration allows software to configure each WQ as a Shared Work Queue/SWQ that receives descriptors using non-posted ENQCMDS instructions]; [0706 - The ENQCMDS instruction enables many clients to subscribe and share work-queue resources on an accelerator]; [0799 - ENQCMDS has the format shown in Fig. 62]; [0800 - The upper 60-bytes in the command descriptor specifies the target device specific command 6201. The PRIV field, bit 31, 6202 is specified by bit 31 in command data at source operand address to convey either user (0) or supervisor (1) privilege for enqueue-stores generated by ENQCMDS instruction. The PASID field, bits 19:0, 6204 conveys the PASID as specified in bits 19:0 in the command data at source operand address1]),
Kumar further discloses,
- wherein the descriptor includes one or more fields to indicate a corresponding one or more permissions tables ([See 112(a), 112(b)]) from which to determine the first PASID and the second PASID (Kumar,
[0049 - When ENQCMD/S instructions are executed in non-root mode and the control bit 325 is enabled, system 300 attempts to translate the guest ASID/PASID 320/first VM PASID in the work descriptor to a Host ASID using the ASID translation table 335. System 300 uses bit 19 in the Guest ASID as an index into the VMCS 330 to identify the two entry ASID translation table 335. The ASID translation table 335 includes a pointer to base address of the first level ASID table 340. The first level ASID table 340 is indexed/source selector by the guest ASID bits 18:10 to identify a ASID table pointer 345 to a base address of the second level ASID table 350, which is indexed/dest selector by the Guest ASID bits 9:0 to find the translated host ASID 355; It is well-known that the hypervisor/VMM uses the host PASID to establish nested PASID translation, guest-to-host, to arrive at the second VM PASID, .i.e. the hypervisor/VMM maintains a mapping table that bridges the guest PASID to a unique host PASID. Therefore the Source/first PASID is the incoming 20-bit guest PASID sent in the PCIe packet. The Destination/second PASID is the translated 20-bit host PASID determined through the nested two-level lookup]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the translation controller of Kumar into the DSA of Sankaran, Deval for the benefit of virtualization of process address space identifiers for scalable virtualization of input/output devices where each ADI/AI is an interface that supports one or more work submissions from the VM. These ADIs enable a guest driver of the VM to submit work directly to the ADI (Kumar, 0007, 0021).
As per Claim 9, it is similar to claim 2 and therefore the same mappings are incorporated.
As per Claim 16, it is similar to claim 2 and therefore the same mappings are incorporated.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm 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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
Prosecution Insights