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

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



On 15/05/15 14:24, Ian Campbell wrote:
> On Fri, 2015-05-15 at 18:44 +0530, Vijay Kilari wrote:
>> On Fri, May 15, 2015 at 6:23 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> 
>> wrote:
>>> On Fri, 2015-05-15 at 18:17 +0530, Vijay Kilari wrote:
>>>> On Fri, May 15, 2015 at 5:33 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>>>> wrote:
>>>>> On 15/05/15 12:30, Ian Campbell wrote:
>>>>>>> Handling of Single vITS and multipl pITS can be made simple.
>>>>>>>
>>>>>>> All ITS commands except SYNC & INVALL has device id which will
>>>>>>> help us to know to which pITS it should be sent.
>>>>>>>
>>>>>>> SYNC & INVALL can be dropped by Xen on Guest request
>>>>>>>  and let Xen append where ever SYNC & INVALL is required.
>>>>>>> (Ex; Linux driver adds SYNC for required commands).
>>>>>>> With this assumption, all ITS commands are mapped to pITS
>>>>>>> and no need of synchronization across pITS
>>>>>>
>>>>>> You've ignored the second bullet its three sub-bullets, I think.
>>>>>
>>>>    Why can't we group the batch of commands based on pITS it has
>>>> to be sent?.
>>>
>>> Are you suggesting that each batch we send should be synchronous? (i.e.
>>> end with SYNC+INT) That doesn't seem at all desirable.
>>
>> Not only at the end of batch, SYNC can be appended based on every
>> command within the batch.
> 
> Could be, but something to avoid I think?

That would slow down the ITS processing (SYNC is waiting that the
previous command has executed).

Also, what about INTALL? Sending it everytime would be horrible for the
performance because it flush the ITS cache.

>> Also to handle second bullet, where a batch of commands might be
>> sent on multple pITS. In that case batch of ITS commands is split
>> across pITS and we have
>> to wait for all the pITS to complete. Managing this would be difficult.
>> For this I propose, batch can be created/split such that each batch
>> contains commands related to one pITS. But it leads to small batch of 
>> commands.

If I understand correctly, even with multiple pITS only a single batch
per domain would be in-flight, right?

> That's not a bad idea, commonly I would expect commands for one device
> to come in a short batch anyway. So long as the thing does cope if not I
> think this might work.

This doesn't work well, we will need to read/validate twice a command.
The first time to get the devID and notice we need to create a separate
batch, the second time to effectively queue the command.

Given that validation is the part where the emulation will spend most of
the time, we should avoid to do it twice.

Although, if we cache the validation we may send the wrong command/data
if the guest decide to write in the command queue at the same time.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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