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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

>>>> If we are going to expose multiple vITS to the guest, we should only use
>>>> vITS for guest using PCI passthrough. This is because migration won't be
>>>> compatible with it.
>>>
>>> It would be possible to support one s/w only vits for migration, i.e the
>>> evtchn thing at the end, but for the general case that is correct. On
>>> x86 I believe that if you hot unplug all passthrough devices you can
>>> migrate and then plug in other devices at the other end.
>>
>> What about migration on platform having fewer/more pITS (AFAIU on cavium
>> it may be possible because there is only one node)? If we want to
>> migrate vITS we should have to handle case where there is a mismatch.
>> Which brings to the solution with one vITS.
> 
> At the moment I don't think we are expecting to do heterogeneous
> migration. But perhaps we should plan for that eventuality, since one
> day it seems people would want to at least move to a newer version of
> the same silicon family for upgrade purposes.

I was think migration within the same version of the silicon.

AFAICT, cavium can be shipped with 1 or 2 nodes. This will result to
have 1 or 2 ITS.

Migration wouldn't be possible between servers using different number of
nodes.

Regards,

-- 
Julien Grall

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