On Mon, Mar 27 2017 at 10:31:03 AM, Eric Auger <eric.auger@xxxxxxxxxx> 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.
