Hi Peter,

On 3/17/21 9:40 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 10:37, Gavin Shan <gs...@redhat.com> wrote:
On 3/17/21 8:09 PM, Peter Maydell wrote:
On Wed, 17 Mar 2021 at 04:44, Gavin Shan <gs...@redhat.com> wrote:

   static const VMStateDescription vmstate_pl011 = {
       .name = "pl011",
       .version_id = 2,
       .minimum_version_id = 2,
+    .post_load = pl011_post_load,
       .fields = (VMStateField[]) {
           VMSTATE_UINT32(readbuff, PL011State),
           VMSTATE_UINT32(flags, PL011State),
@@ -355,10 +355,6 @@ static const VMStateDescription vmstate_pl011 = {
           VMSTATE_INT32(read_trigger, PL011State),
           VMSTATE_END_OF_LIST()
       },
-    .subsections = (const VMStateDescription * []) {
-        &vmstate_pl011_clock,
-        NULL
-    }
   };

Doesn't dropping the subsection break migration compat ?


It's why this patch needs to be backported to stable branches.
In that way, we won't have migration compatible issue.

No, migration has to work from the existing already
shipped 5.1, 5.2, etc releases to 6.0 (assuming you use
the correct "virt-5.2" &c versioned machine type.)


Commit aac63e0e6ea3 ("hw/char/pl011: add a clock input") is merged
to v5.2.0. The migration failure happens during migration from v6.0
to v5.1 with machine type as "virt-5.1", instead of migrating from
v5.1 to v6.0. One question is if we need support backwards migration?

If we do support backwards migration, I think there are two options:
(1) merge this patch and backport it to v5.2+; (2) Backport commit
aac63e0e6ea3 to v5.2-. I guess (1) would be right way to go because
it's less effort than (2). Besides, the clock needn't to be migrated
if I'm correct.

Thanks,
Gavin


Reply via email to