On Fri, Aug 12, 2022 at 07:23:09PM -0300, Daniel Henrique Barboza wrote: > > > On 8/8/22 00:26, David Gibson wrote: > > On Fri, Aug 05, 2022 at 06:39:38AM -0300, Daniel Henrique Barboza wrote: > > > The pSeries machine never bothered with the common machine->fdt > > > attribute. We do all the FDT related work using spapr->fdt_blob. > > > > > > We're going to introduce HMP commands to read and save the FDT, which > > > will rely on setting machine->fdt properly to work across all machine > > > archs/types. > > > > > > Let's set machine->fdt in the two places where we manipulate the FDT: > > > spapr_machine_reset() and CAS. spapr->fdt_blob is left untouched: what > > > we want is a way to access the FDT from HMP, not replace > > > spapr->fdt_blob. > > > > Given there is now an fdt field in the generic MACHINE structure, we > > should be able to remove the one in spapr->fdt_blob, yes? > > I thought about it but I backed down when I realized that spapr->fdt_blob is > being migrated. > > At first glance it would be a matter of migrating ms->fdt and then removing > spapr->fdt_blob, but then I got confused about how a migration to an older > version would occur (e.g. QEMU 7.2 with ms->fdt to a QEMU 7.0 with > spapr->fdt_blob). > > Migration to a newer QEMU would require us to move the spapr->version_id to 4 > and then handle the old version accordingly in spapr_post_load(). > > Probably something to think about after this work is accepted.
Fair enough. I'm confident the migration semantics can be worked out,
but it will require some care.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
