Clarification on cross-version compatibility requirements

Clarification on cross-version compatibility requirements

[Klaus Jensen]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

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.

Can anyone enlighten me on the guidelines (de-facto requirements) for
this?


Thanks,
Klaus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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