Hi
On Mon, Oct 2, 2023 at 6:42 PM Laszlo Ersek <ler...@redhat.com> wrote:
>
> On 10/2/23 13:11, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lur...@redhat.com>
> >
> > For compatibility reasons.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> > ---
> > hw/core/machine.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 68cb556197..2fa7647422 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -30,7 +30,10 @@
> > #include "hw/virtio/virtio-pci.h"
> > #include "hw/virtio/virtio-net.h"
> >
> > -GlobalProperty hw_compat_8_1[] = {};
> > +GlobalProperty hw_compat_8_1[] = {
> > + { "ramfb", "migrate", "off" },
> > + { "vfio-pci-nohotplug", "ramfb-migrate", "off" }
> > +};
> > const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);
> >
> > GlobalProperty hw_compat_8_0[] = {
>
> In the other discussion, you mentioned the concrete reason for this -- I
> think if we don't do this, then the ramfb vmstate blocks backward
> migration? Can you document the reason here explicitly (commit message,
> I mean, doesn't have to be a code comment)?
By using device section/subsection in v3, I changed a little bit the
reasons for the properties. Now it falls under the common issue
documented in migration.rst "Changing migration data structure".
>From v3, let me know if you still think we should document that better
in the commit message.
thanks
--
Marc-André Lureau
