* Cleber Rosa (cr...@redhat.com) wrote: > On Thu, Dec 05, 2019 at 12:01:56PM +0100, Philippe Mathieu-Daudé wrote: > > > > Understood, thanks for clearing this out! > > > > Side note, we don't do cross-arch migration testing, but we talked about > > having a 'different QEMU version' migration test. When we get a such test > > setup, it shouldn't be too difficult to evolve to some cross-arch migration > > test. > > > > +Oksana, > > Avocado-VT has had this as a core concept as far as I can remember, and > it's exposed even as a command line argument: > > avocado run --help > ... > [--vt-qemu-dst-bin VT_DST_QEMU_BIN] > ... >
Yeh, I've run that in the past - it works OK. Dave > Oksana is currently working on new migration test cases, and may consider > looking into adding "different QEMU version" support too. > > PS: I have to say, though, that I'm trying to get my mind around > cross-arch migration being real. > > - Cleber. > > > > > I hope I'm wrong and confuse, this is a great news for me to know we > > > > can migrate floats! > > > > > > > > > Dave > > > > > > > > > > > > So we could store the frequency in clock out and migrate things > > > > > > > there. > > > > > > > But since we have no way to ensure all clock out states are > > > > > > > migrated > > > > > > > before some device fetch a ClockIn: we'll have to say "don't > > > > > > > fetch one > > > > > > > of your ClockIn frequency during migration and migrate the value > > > > > > > yourself if you need it", pretty much like gpios. > > > > > > > > > > > > > > So we will probably migrate all ClockOut and almost all ClockIn. > > > > > > > > > > > > > > It would nice if we had a way to ensure clocks are migrated before > > > > > > > devices try to use them. But I don't think this is possible. > > > > > > > > > > > > > > -- > > > > > > > Damien > > > > > > > > > > > > > > > > > > -- > > > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > > > > > > > > -- > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK