>> GlobalProperty hw_compat_4_2[] = { >> { "virtio-blk-device", "queue-size", "128"}, >> { "virtio-scsi-device", "virtqueue_size", "128"}, > > Okay, so the bit above is for after 5_0 is released then? Is there a
Yes. > way to queue up a reminder or something so we get to it when the time > comes, or I just need to watch for 5.0 to come out and submit a patch > then? I think what happened usually happens is that someone introduces all the compat machines, sometimes directly with empty hw_compat. E.g., see commit 3eb74d2087d3bd6cb51c06a49ba94222248d2de4 Author: Cornelia Huck <coh...@redhat.com> Date: Tue Nov 12 11:48:11 2019 +0100 hw: add compat machines for 5.0 Add 5.0 machine types for arm/i440fx/q35/s390x/spapr. and commit 9aec2e52ce9d9632a86be2d1d0dd493722d2e7be Author: Cornelia Huck <coh...@redhat.com> Date: Wed Jul 24 12:35:24 2019 +0200 hw: add compat machines for 4.2 Add 4.2 machine types for arm/i440fx/q35/s390x/spapr. The latter already introduced hw_compat_4_1, for examnple. @Conny, do you already have a patch for 5.1 compat patch lying around somewhere? [...] > So I will probably go this route. It looks like that is the way we > went for free page reporting so it is easy enough to just do some > cut/paste/replace and have something ready to go later today without > having to second guess things. I remember that a v1->v2 vmstate migration works (e.g., old QEMU to new QEMU). But I can't tell from the top of my head what would happen when we migrate v2->v1 (e.g., new QEMU to old QEMU). My guess is that the latter won't work, but I might be wrong. Looking at migration/vmstate.c:vmstate_load_state() "incoming version_id ... is too new for local version_id" One would have to tell the new QEMU to send via vmstate v1 when running under the compat machine. I don't recall if and how that would be possible. So the other approach is a save bet. -- Thanks, David / dhildenb