[PATCH v4 08/22] KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_iidr

[Auger Eric]

Marc,

On 11/04/2017 12:05, Marc Zyngier wrote:
> On 10/04/17 16:17, Auger Eric wrote:
>> Hi Marc,
>>
>> On 10/04/2017 16:57, Marc Zyngier wrote:
>>> On 10/04/17 15:32, Auger Eric wrote:
>>>> Hi Marc,
>>>>
>>>> On 08/04/2017 12:42, Marc Zyngier wrote:
>>>>> On Mon, Mar 27 2017 at 10:30:58 AM, Eric Auger <eric.auger at redhat.com> wrote:
>>>>>> The GITS_IIDR revision field is used to encode the version of the
>>>>>> table layout (ABI). So we need to restore it to check the table
>>>>>> layout to be restored is compatible with the destination vITS.
>>>>>>
>>>>>> The user selected revision is stored in the user_revision field.
>>>>>> It will be compared against the REV num at table restoration time.
>>>>>
>>>>> Why isn't it sufficient to keep it GITS_IIDR RO and let userspace find
>>>>> out about the ABI revision that the kernel understands?
>>>>>
>>>>> Or are we planning on supporting multiple ABIs in the kernel?
>>>> Yes as discussed with Peter, the plan is to allow several ABIs. So the
>>>> userspace informs the destination about the ABI revision of the stored
>>>> tables (contained by the GITS_IIDR). If the destination KVM does not
>>>> support this ABI revision, table restore will fail.
>>>>  If so, do
>>>>> we have a deprecation policy/plan? I don't mind either way, but it would
>>>>> be good to document it...
>>>>>
>>>>> Maybe it is documented already and I missed it (which is perfectly
>>>>> possible!).
>>>> Well this is partly documented in
>>>> Documentation/virtual/kvm/devices/arm-vgic-its.txt. No plan to
>>>> deprecate. migration from KVM supporting v1 to KVM supporting V2 would
>>>> be possible but not the contrary.
>>>>
>>>> Does it make sense?
>>>
>>> Sort of. Say you have three systems: A and C, which only supports v1; B,
>>> which supports v1 and v2. Let's say you migrate from A to B, and from B
>>> to C. Is B mandated to be able to export the tables as v1 and v2? Or can
>>> it restrict what it can export?
>> At the moment migration from B to C will fail because source ABI rev =
>> v2 > destination support ABI = v1.
>>
>> A (v1) -> B (v1 & v2): migration OK
>> B (v1 & v2) -> C (v1): migration NOK
> 
> So what does IIDR report on B once the A->B migration has taken place?
> Does it report v2?

yes that was the plan

Thanks

Eric
> 
> Thanks,
> 
> 	M.
>