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 4:05 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> Hi,
>
> On 28/04/15 10:56, Stefano Stabellini wrote:
>> On Tue, 28 Apr 2015, Vijay Kilari wrote:
>>> Approach 1: (Using completion interrupt)
>>> ----------------
>>> 1) Create dummy device for each virtual ITS when virtual its is
>>> created for a domain
>>>     OR Allocate one interrupt number for each virtual ITS from the one
>>> single dummy device
>>>
>>> 2) Trap on CWRITER
>>> 3) Take vits lock
>>> 4)     Read a Virtual Command from Virtual Command Queue
>>> 5)     Translate Virtual command to Physical command
>>> 5)  Release vits lock
>>> 6) Take physical ITS lock
>>> 7)      Post physical commands + Append INT command
>>> 8) Release physical ITS lock
>>> 9) Return from CWRITER trap and let VCPU poll in EL1 (kernel) for CREADER 
>>> update
>>>     which indicates completion of command.
>>> 10) On receiving interrupt, Update CREADER of this virtual ITS
>>>
>>> Pros:
>>>     - VCPU polls in EL1.
>>>
>>> Cons:
>>>     - Complexity in creating & managing dummy device.
>
> 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

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.

Regards
Vijay

>
>>> Approach 2:
>>> ----------------
>>> I thought of below approach where in we reduce locking time and no need
>>> of Interrupt.
>>>
>>> 1) Trap on CWRITER
>>> 2) Take vits lock
>>> 3)     Read _all_ or 2 Virtual Commands from Virtual Command Queue
>>> 4)     Translate _all_ or 2 Virtual commands to Physical commands
>>> 5)  Release vits lock
>>> 6) Take physical ITS lock
>>> 7)      Post physical commands
>>> 8) Release physical ITS lock
>>> 9) Poll for completion of command and return from CWRITER trap.
>>>
>>> Pros:
>>>     - Simple approach
>>> Cons:
>>>     - VCPU polls in EL2
>>
>> I think we'll have to go with Approach 1.
>>
>> The problem with Approach 2 is that we would need to watch out for
>> sequences of guest ITS commands that could cause Xen to poll for too
>> long and lock up.
>
> +1, the approach 1 is the best.
>
> Regards,
>
> --
> Julien Grall

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