Re: [PATCH for-7.2 v2 10/20] hw/ppc: set machine->fdt in spapr machine

[David Gibson <david@gibson.dropbear.id.au>]

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

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

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