On Feb 03 13:44, Andrew Jones wrote: > On Wed, Feb 03, 2021 at 10:52:59AM +0000, Peter Maydell wrote: > > On Wed, 3 Feb 2021 at 10:49, Dr. David Alan Gilbert <dgilb...@redhat.com> > > wrote: > > > > > > * Peter Maydell (peter.mayd...@linaro.org) wrote: > > > > On Wed, 3 Feb 2021 at 10:28, Dr. David Alan Gilbert > > > > <dgilb...@redhat.com> wrote: > > > > > > > > > > * Philippe Mathieu-Daudé (phi...@redhat.com) wrote: > > > > > > Cc'ing migration team and qemu-arm@ list. > > > > > > > > > > I'll have to leave the detail of that to the ARM peole; but from a > > > > > migration point of view I think we do want the 64 bit ARM migrations > > > > > to > > > > > be stable now. Please tie incompatible changes to machine types. > > > > > > > > That is the intention, but because there's no upstream testing > > > > of migration compat, we never notice if we get it wrong. > > > > What is x86 doing to keep cross-version migration working ? > > > > > > I know there used to be some of our team running Avocado tests for > > > compatibility regularly, I'm not sure of the current status. > > > It's something we also do regularly around when we do downstream > > > releases, so we tend to catch them then, although even on x86 that > > > often turns out to be a bit late. > > > > So downstream testing only? > > Not even downstream for the Arm architecture, at least not at Red Hat. The > support we have for Arm Virt is still limited to the use cases for which > it has been deployed. To this day that hasn't included migration[*]. > > > I think that unless we either (a) start > > doing migration-compat testing consistently upstream or > > This is the best choice and it can certainly be an additional approach > regardless of what goes on downstream. I can look into this. A pointer > to the x86 tests would be a good start. It's pretty simple to do a > quick migration test between two versions of QEMU, but we need the > whole build two versions of QEMU stuff first, which I hope already > exists.
Does this mean that this is largely an issue of developing the tests, and not a need for a place to host them? Or would additional hardware/hosting be required for these tests to be run on? -Aaron