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

Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support



On 29/04/15 17:30, Vijay Kilari wrote:
> On Wed, Apr 29, 2015 at 9:56 PM, Vijay Kilari <vijay.kilari@xxxxxxxxx> wrote:
>> On Wed, Apr 29, 2015 at 7:05 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>> wrote:
>>> On 29/04/15 12:56, Julien Grall wrote:
>>>> As the 2 suggested approach don't seem to fit our usage, we need to find
>>>> another approach.
>>>
>>> I think I have another approach which doesn't require interrupt neither
>>> polling in EL2.
>>
>> I could resolve all the issues around approach 1
>> only concern is generating dummy/fake device id.

This is a big concern. We can't hardcode the devID because a real device
could use it later. Having an ID generating at the boot time wouldn't be
better because it could be broken with device hotplug.

It's very unfortunate that the ITS doesn't have a reserved interrupt.

So, I think we need to rule out the interrupt completion.

>>
>> However with INT mode, if the guest driver is checking for CREADR
>> value on receiving completion interrupt requested through INT ITS command
>> then CREADR will show up old value.
> 
>   On trap of CREADR we have to update it. So this can be handled

Unfortunately not. We need to work in batch mode in order to have a
simple and secure implementation. This would restrict the number of
commands sent together. So the INT command may be sent in another batch.

Furthermore, if the command queue is full we need to defer the rest of
the guest (rather than discarding the command as you do now).

I'm open to other approach as long as they are secured. By secure, I
mean, no polling in EL2 and no possibility to take down another guest
(for instance by flooding the command queue).

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®.