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

[Vijay Kilari <vijay.kilari@xxxxxxxxx>]

On Tue, Apr 28, 2015 at 9:45 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi Vijay,
>
> On 28/04/15 12:36, Vijay Kilari wrote:
>> On Tue, Apr 28, 2015 at 4:05 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>> wrote:
>>> If you properly manage the device with struct pci_dev or struct device
>>> (which is, as talked earlier, obviously required for security) you
>>> should avoid your so-called "dummy device". BTW, what do you mean by
>>> "dummy device"?
>>
>>
>> (a) For implementing ITS command processing completion interrupt we need
>> a unique interrupt for each domain per vITS to update corresponding virtual 
>> ITS
>> CREADER
>> (b) INT command requires dev,ID there needs to be a device
>> associated with the ID
>> (c) The command processing completion interrupt is not coming from a
>> valid device, we have to provide a dummy device,ID
>> (d) I propose that the dummy device segment number is read from a
>> macro/helper function
>> in the platform file.
>> For each domain we can add the bus number so for eg: 0xff is the segment
>> number which is #define PLAT_DUMMY_SEG 0xff.
>> The device for dom0 would be PLAT_DUMMY_SEG:00:0.0
>> The device for domU would be PLAT_DUMMY_SEG:00:0.0 | domain_id
>
> There is multiple problem with this solution:
>         - What prevents a platform to use this Device ID in the future?

Nothing prevents. But we can make a check in the ITS driver.

>         - What's is the behavior of the ITS when the Device ID doesn't belong
> to a real device?
            ITS behavior is same for any device ID provided it falls
in Devbits range

>         - The number of bits for the Device ID can be limited via
> GITS_TYPER.Devbits, so it's not possible to use an hardware value

For ITS any Device ID should fall withing the Devbits range. Otherwise
ITS cannot create/prase ITT table and generate interrupt

>
>> Let me know if there is better way to generate dummy/unused device id?
>>
>> So creation of dummy device and setup for INT command execution
>> can be done in physical ITS driver with its_device structure managed
>> in vgic_its
>>
>> Also with this approach, vITS is not held by the VCPU till the completion
>> of command processing, So another VCPU of the same domain can add
>> another ITS command. If so we have to keep track number of ITS commands
>> being processed per VCPU of the domain and increment vITS CREADER 
>> accordingly.
>> For this, we have to add one unique interrupt ID of the device for per
>> VCPU, So that
>> unique interrupt is received from the dummy device for per VCPU.
>
> The number of LPIs supported by the ITS could be very limited. We need
> to use them with parsimony.

Per device we can generate upto 2K MSIx. With dummy device we can
use without restriction.

>
> Even if you have a per-VCPU  interrupt, it doesn't prevent a same vCPU
> writing other commands after a first batch then wait.

Yes, This case should be managed.

Managing all this complexity, What is the problem with Approach 2?
We have time bound polling which loops only for few ms and that too
ITS is not in critical path.
It is only used when configuring interrupts of the device?

Regards
Vijay

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