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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 19/05/15 13:14, Ian Campbell wrote:
> On Fri, 2015-05-15 at 14:24 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 15/05/15 13:58, Ian Campbell wrote:
>>>>>>>>> Therefore it is proposed that the restriction that a single vITS maps
>>>>>>>>> to one pITS be retained. If a guest requires access to devices
>>>>>>>>> associated with multiple pITSs then multiple vITS should be
>>>>>>>>> configured.
>>>>>>>>
>>>>>>>> Having multiple vITS per domain brings other issues:
>>>>>>>>        - How do you know the number of ITS to describe in the device 
>>>>>>>> tree at boot?
>>>>>>>
>>>>>>> I'm not sure. I don't think 1 vs N is very different from the question
>>>>>>> of 0 vs 1 though, somehow the tools need to know about the pITS setup.
>>>>>>
>>>>>> I don't see why the tools would require to know the pITS setup.
>>>>>
>>>>> Even with only a single vits the tools need to know if the system has 0,
>>>>> 1, or more pits, to know whether to vreate a vits at all or not.
>>>>
>>>> In the 1 vITS solution no, it's only necessary to add a new gic define
>>>> for the gic_version field in xen_arch_domainconfig.
>>>
>>> Would we expose a vITS to guests on a host which has no pITS at all?
>>
>> No, Xen will check if we can support vITS. See an example with my "GICv2
>> on GICv3" series. Obviously, we don't allow vGICv3 on GICv2.
> 
> Did you mean to refer to "arm: Allow the user to specify the GIC
> version" or some other part of that series?

Yes I mean this patch.

> I suppose you are proposing a new flag vits=yes|no passed as part of the
> domain config which Xen can then update to indicate yes or no? Or is
> there more to it than that? Could Xen not equally well expose nr_vits
> back to the tools?

A new flag or extending gic_version parameters (gic_version = "v3-its").

With the multiple vITS we would have to retrieve the number of vITS.
Maybe by extending the xen_arch_domainconfig?

Regards,

-- 
Julien Grall

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