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@xxxxxxxxxx> 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? Thanks Eric > > Thanks, > > M. >
