[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

On Tue, May 5, 2015 at 7:21 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Tue, 5 May 2015, Vijay Kilari wrote:
>> Proposal 2:
>> ----------------
>> Here when guest writes command to vITS queue and updates CWRITER registers,
>> it is trapped in XEN and below steps are followed to process ITS command
>> - Dom0 creates a ITS completion device with device id (00:00.1) and reserves
>>   n number (256 or so) irqs (LPIs) for this device.
>> - One irq/LPI (called completion_irq) of this completion device is
>> allocated per domain
> Good. Is it possible to actually assign an LPI to a domain when/if a PCI
> device is assigned to the domain? So that we don't waste LPIs for
> domains that are not going to use the vITS?

Yes we can. On receiving first MAPD command we can allocate LPI.

>> - With this irq/LPI descriptor we can identify the domain/vITS.
>> - Info of all the ongoing ITS requests(put in pITS Queue) of this domain is
>>   stored in ITS command status array (called its_requests). This is
>> managed per vITS.
>> 1) Trap of CWRITER write by guest
>> 2) Take vITS lock
>> 3) Read all the commands written by guest, translate it
>>     - If one of the guest command is INT command
>>        a) Append INT command with completion_irq and write this batch as
>>           seperate request and goto (3) to process next commands
>>     - If more than 'n' commands are sent by guest, start a timer to process
>>       remaining commands
>> 4) Append INT command with completion_irq of current domain
> I would consider adding a vcpu_block call
>> 5) Release vITS lock
>> 6) Take physical ITS (pITS) lock
>> 7) Write translated cmds to physical ITS
>> 8) Add entry in its_requests
>> 9) Release pITS lock
>> 10) return from trap
>> One receiving completion interrupt:
>> 1) Take the first pending request from its_requests.
>> 2) Update vITS CREADER of the guest indicating completion of command to guest
> I would add vcpu_unblock
>> Cons:
>>    - Has overhead of processing completion interrupt.
>>    - Need to reserve a fake device to generate completion interrupt and
>>      reserve one LPI per-domain
>> Pros:
>>    - VCPU does not poll in Xen for completion of commands.
>>    - Handles guest flooding command queue with commands. But needs timer
>> Handling Command queue state:
>>  - Physical Queue cannot be full as it 64KB there by it can accomodate
>> 1K ITS commands.
>>    In case it is full, VCPU has to poll with timeout till physical
>> Queue is empty before it post
>>    next command
>>  - If vITS Queue condition should be managed by guest ITS driver.
>> Behaviour of Polling and completion interrupt based guest driver:
>>  - If completion interrupt (INT) is used by guest driver, then insert
>> Xen completion
>>    INT command so that CREADER is updated before guest's INT command is 
>> injected
>>  - If polling mode is used, trap on CREADER checks for completion of command

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.