"Michael S. Tsirkin" <m...@redhat.com> wrote: [adding cleber]
> On Thu, May 18, 2023 at 09:27:01AM -0400, Peter Xu wrote: >> One thing we can also do to avoid it in the future is simply having someone >> do this check around each softfreeze (and we'll also need maintainers be >> careful on merging anything that's risky though after softfreeze) rather >> than after release (what I did for this time, which is late), try to cover >> as much devices as possible. I don't know whether there's a way to always >> cover all devices. >> >> I'll volunteer myself for that as long as I'll remember. Juan, please also >> have a check or remind me if I didn't. :) >> >> I am not sure whether I mentioned it somewhere before, but maybe it'll work >> if we can also have some way we check migrating each of the vmsd from >> old-qemu to new-qemu (and also new->old) covering all devices. It doesn't >> need to be a real migration, just generate the per-device stream and try >> loading on the other binary. >> >> It might be an overkill to be part of CI to check each commit, but if >> there's some way to check it then at least we can run it also after >> softfreeze. I also don't know whether it'll be easy to achieve it at all, >> but I'll think more about it too and update if I found something useful. > > I'm all for more testing but if it does not actually test that the > values loaded are actually used correctly then the testing is of course > lower quality. Better than nothing I guess ... As said in my other email. The problem that I have is that there is no easy way to test two different qemu binaries. And what we would like is testing at least: qemu-8.0 -M pc-8.0 -> qemu-latest -M pc-8.0 qemu-latest -M pc-8.0 -> qemu-8.0 -M pc-8.0 Then we have the probem of: - what architectures do we care? My bet is on x86_64, i386? (almost free with previous one), ppc64, aarch64, s390. - what devices do we care? virtio-devices for sure. Not sure with others. Notice that if we want the test to run on CI, they need to be virtual devices. Once the mechanism of testing and reporting is there, we can decide: - what other devices we care no good ideas here: SATA, e1000e perhaps. - what other versions we care perhaps it is not out of qestion to test the last two versions. i.e. to add: $ qemu-7.2 -M pc-7.2 -> qemu-latest -M pc-7.2 $ qemu-latest -M pc-7.2 -> qemu-7.2 -M pc-7.2 But we haven't been very good just allowing the latest version to add the latests two. Cleber, any idea how difficult would be to add something like that? For reference, we are trying to test, detect the failures described here: https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg03285.html See the three emails. Thanks, Juan.
