Re: Clarification on cross-version compatibility requirements

[Peter Maydell]

On Fri, 23 Feb 2024 at 10:25, Klaus Jensen <its@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