Subject: [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group

From: [email-masked] (Marc Zyngier)
Date: Sun, 09 Apr 2017 11:09:53 +0100

On Mon, Mar 27 2017 at 10:31:03 AM, Eric Auger <[email-masked]> wrote:
> Introduce a new group aiming at saving/restoring the ITS
> tables to/from the guest memory.
>
> We hold the vcpus lock during the save and restore to make
> sure no vcpu is running.
>
> At this stage the functionality is not yet implemented. Only
> the skeleton is put in place.
>
> The ABI revision supposed to have been set through IIDR user
> write is checked before the table restoration. This guarantees
> this vITS knows how to restore the saved tables.

This last point hints at the kernel side being able to deal with
multiple versions of the ABI. As I mentioned before, this requires some
clarification on what we plan to support, and whether or not we are able
to deprecate ABIs in the long run

One thing that is not clear to me is that although you want to be able
to restore the vITS using a given ABI, should you be able to save it
using that same ABI? Or does a restore/save cycle act as an ABI upgrade
for this VM?

I'd also like to see some infrastructure in the code to support this, in
the form of a per-ABI array of support functions (even if we only have
one ABI for the time being). Although that's not required ATM, it would
certainly halp me understanding what is ABI-specific and what's not.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.