Re: Rust high-level pre/post migration callbacks

[Manos Pitsidianakis <manos.pitsidianakis@linaro.org>]

On Mon, Sep 8, 2025 at 1:19 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 9/8/25 12:02, Manos Pitsidianakis wrote:
> > Hi Paolo,
> >
> > I'm not familiar with how migration works under the hood, but this
> > data transformation design looks very clean and neat to me.
>
> Thanks!
>
> >> Using it is very easy, you can just declare your state like:
> >>
> >>       regs: Migratable<Mutex<MyDeviceRegisters>>
> >
> > Hm it's a shame we cannot do this with a trait since it requires state
> > storage for migration_state.
>
> Yeah, but a Box is just a single pointer.  We need to have an actual
> location in memory for the C code to retrieve the pointer.

Oh yeah I got that. I was talking about needing to introduce new
wrapper types for fields.

>
> > A suggestion: we could declare a "mirror" struct to hold
> > `migration_state` with a Derive macro. This is what the `rkyv` crate
> > does with its `Archive` derive macro and trait
> > <https://docs.rs/rkyv/latest/rkyv/trait.Archive.html>
>
> Nice!  I'm not familiar with rkyv but it does look very similar.
>
> When I tried to clean up the HPET (create HPETRegisters, and replace use
> of raw pointers with self_cell to implement self-referential structs),
> migration was the big mess, so I hope that this design will fix both
> that and Mutex<>.  And indeed having a derive macro is very similar to
> what I came up with one day later :) while thinking about how HPET could
> use it in practice.
>
> Probably the derive macro would require some changes to the trait, but
> the basic idea remains the same.

Yes exactly. You could store the migration data in another struct
(e.g. `FooDeviceMigrationState`) and use it as a conduit between the
device and C migration logic.

>
> Paolo
>