Virtual container storage interface controller
US-12175078-B2 · Dec 24, 2024 · US
US2016210167A1 · US · A1
| Field | Value |
|---|---|
| Publication number | US-2016210167-A1 |
| Application number | US-201315023694-A |
| Country | US |
| Kind code | A1 |
| Filing date | Sep 24, 2013 |
| Priority date | Sep 24, 2013 |
| Publication date | Jul 21, 2016 |
| Grant date | — |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Technologies are generally provided to virtualize hardware acceleration. In some examples, a coprovisor component may be configured to multiplex multiple domains' requests to access a hardware accelerator such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a comparable accelerator in a paravirtualized environment. Hyper-requesting may be employed for hardware acceleration virtualization, where a hardware acceleration module concurrently loads a portion of data of a request for a first accelerator application and a portion of data of another request for a second accelerator application and simultaneously processes the two portions of data. Directly situated on a device driver layer, the coprovisor may schedule portions of access requests to the hardware accelerator at the same time through direct memory access (DMA) context switching.
Opening claim text (preview).
1 . A method to access a virtualized hardware acceleration module, the method comprising: identifying a first access request from a first virtual machine (VM) for a first accelerator application executable on the hardware acceleration module; identifying a second access request from a second VM for a second accelerator application executable on the hardware acceleration module; scheduling the first access request and the second access request using a coprovisor; and causing the hardware acceleration module to process at least a portion of the first access request and a portion of the second access request by loading the portion of the first access request for the first accelerator application and the portion of the second access request for the second accelerator application and simultaneously processing the first and second portions of the access requests. 2 . (canceled) 3 . The method of claim 1 , wherein the hardware acceleration module is part of one of: a field-programmable gate array (FPGA) and an application specific integrated circuit (ASIC). 4 . The method of claim 1 , wherein the first accelerator application and the second accelerator application are executable on the hardware acceleration module at a same time. 5 . The method of claim 1 , further comprising: identifying a first data block associated with the first access request via a first shared memory space; and identifying a second data block associated with the second access request via a second shared memory space, wherein the first and second shared memory spaces comprise a group of physical memory pages used for user-kernel space data transfer in a VM and an inter-VM data transfer; and wherein the first and second shared memory spaces are accessed by the hardware acceleration module for data fetching and writing back. 6 . (canceled) 7 . The method of claim 5 , further comprising adjusting a size associated with at least one of the first shared memory space and the second shared memory space based on a priority associated with at least one of the first VM and the second VM. 8 . The method of claim 1 , wherein; the first and second access requests for the first and second accelerator applications are executed in a direct memory access (DMA) read operation stage, an accelerator application computation stage, and a DMA write operation stage; and the DMA read operation stage and the DMA write operation stage are implemented substantially simultaneously. 9 . (canceled) 10 . The method of claim 1 , wherein scheduling the first access request and the second access request includes scheduling the first access request and the second access request based on at least one of a first memory access context associated with the first accelerator application and a second memory access context associated with the second accelerator application; and the first memory access context and the second memory access context are based on RCBs associated with one of the first VM and the second VM accessing the first accelerator application and the second accelerator application, respectively. 11 . (canceled) 12 . The method of claim 1 , wherein scheduling the first access request and the second access request includes scheduling the first access request and the second access request by inserting the first access request in a first request queue associated with the first accelerator application and inserting the second access request in a second request queue associated with the second accelerator application. 13 . The method of claim 1 , wherein causing the hardware acceleration module to process includes causing the hardware acceleration module to process the portion of the first access request and/or the portion of the second access request based on a status of the hardware acceleration module. 14 . The method of claim 13 , further comprising retrieving at least one of the status of the hardware acceleration module and a status of a device driver associated with the hardware acceleration module from an accelerator status word. 15 . The method of claim 1 , wherein causing the hardware acceleration module to process includes causing the hardware acceleration module to process the portion of first access request and/or the portion of the second access request using a pipelining process including at least one of: increasing a computation frequency associated with a computation core for at least one of the first accelerator application and/or the second accelerator application; increasing a number of computation cores associated with at least one of the first accelerator application and/or the second accelerator application; delaying a start time of a memory read operation associated with at least one of the first accelerator application and the second accelerator application; delaying a start time of a computation operation associated with at least one of the first accelerator application and the second accelerator application; and simultaneously executing a memory access read operation and a memory access write operation associated with one of the first access request and the second access request for the first accelerator application and the second accelerator application, respectively. 16 . A coprovisor configured to virtualize a hardware acceleration module, the coprovisor comprising: a request insertion module executable on a processor, the request insertion module configured to: identify a first access request from a first virtual machine (VM) for a first accelerator application executable on the hardware acceleration module; and identify a second access request from a second VM for a second accelerator application executable on the hardware acceleration module; a scheduler module executable on a same processor, the scheduler module configured to schedule the first access request and the second access request; and the coprovisor configured to cause the hardware acceleration module to process at least a portion of the first access request and a portion of the second access request by loading the portion of the first access request for the first accelerator application and the portion of the second access request for the second accelerator application and simultaneously processing the first and second portions of the access requests. 17 . The coprovisor of claim 16 , wherein the first VM and the second VM are same. 18 . (canceled) 19 . The coprovisor of claim 16 , wherein the first accelerator application and the second accelerator application are executable on the hardware acceleration module at a same time. 20 . The coprovisor of claim 16 , wherein the coprovisor is further configured to identify: a first data block associated with the first access request via a first shared memory space; and a second data block associated with the second access request via a second shared memory space, wherein the first and second shared memory spaces comprise a group of physical memory pages used for user-kernel space data transfer in a VM and an inter-VM data transfer; and wherein the first and second shared memory spaces are accessed by the hardware acceleration module for data fetching and writing back. 21 . (canceled) 22 . The coprovisor of claim 20 , wherein the coprovisor is further configured to adjust a size associated with at least one of the first shared memory space and the second shared memory space based on a priority associated with at least one of the first VM and the second VM.
Reconfiguration support, e.g. configuration loading, configuration switching, or hardware OS · CPC title
Memory management, e.g. access or allocation · CPC title
I/O management, e.g. providing access to device drivers or storage · CPC title
Hypervisor-specific management and integration aspects · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.