Hi, On 11/04/2017 12:29, Marc Zyngier wrote: > On 11/04/17 11:16, Peter Maydell wrote: >> On 11 April 2017 at 11:08, Auger Eric <eric.auger@xxxxxxxxxx> wrote: >>> On 11/04/2017 12:05, Marc Zyngier wrote: >>>> On 10/04/17 16:17, Auger Eric wrote: >>>>> 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 >> >> Hmm, the IIDR value shouldn't change across a migration I think. >> It's guest visible so the guest should see it still the same >> value even after migration. > > That's my worry. But we then have a problem when this VM migrates again. > How does userspace find out which ABI to use then? Today the userspace just conveys the information from source kernel to destination kernel through the IIDR value. This allows the destination kernel to know what was the table layout used during the migration. If we report the source ABI revision value on the destination, what is the strategy we should adopt: - limit the features to those that will be migratable through this ABI - allow the functionalities (GICv4 for instance) but reject save? Thanks Eric > > Thanks, > > M. >
