On Fri, 23 Feb 2024 at 10:25, Klaus Jensen <i...@irrelevant.dk> wrote: > > Hi all, > > Yesterday, a bug but in hw/nvme (#2184) was filed > > https://gitlab.com/qemu-project/qemu/-/issues/2184) > > The reporter ran into an issue with hibernating a guest from QEMU v4.1.0 > and trying to resume it on v8.2.1. hw/nvme has received some changes > since then, including a change in the BAR layout which causes the boot > to fail. > > Now, hw/nvme is marked 'unmigratable'. I realize that this is only > observed and checked under live migration, but I honestly did not know > that hw/nvme were expected to ensure that the kind of "hibernation > migration" works. > > I already have a potential fix for the issue (because I don't just want > to say "wontfix", I'd like to fix it), but it got me thinking about what > the general requirements are. And I couldn't find any good documentation > on it. > > So, my question is: when is an emulated device required to support such > version compatibility? I'm asking because we've also deprecated some > stuff, like the device originally using an internal Intel PCI device id > that we wanted to get rid of. But now, I don't think I can actually > remove that parameter, I need to keep it around for hw/core/machine.c to > set if necessary.
So I think the answer is roughly "if it can be sensibly used in a versioned machine type" (we might make exceptions for obviously prototype/testing/whatever devices). It doesn't come up very often, because there aren't that many parts of device behaviour that are observable across hibernate-and-resume an the parts that are are usually nailed down by the hardware specification. -- PMM
