Re: [Qemu-devel] [PATCH v2] migration: discard non-migratable RAMBlocks

[Dr. David Alan Gilbert]

* Peter Maydell (address@hidden) wrote:
> On 9 May 2018 at 12:08, Dr. David Alan Gilbert <address@hidden> wrote:
> > This thread seems to have stalled; we've got the list of potential
> > migration breaks that Peter found and only some minor comments on the
> > actual patch.
> >
> > I'd like to get it going again sicne as well as Cédric, and Peter's
> > cases, there's Lai Jiangshan and now Eric Wheeler was asking for
> > something similar.
> >
> > Anyone understand the way forward? Do we have to go and fix the
> > odd board failures first?
> 
> aspeed and highbank I already changed in master. That leaves
> 
> hw/mips/boston.c:    memory_region_init_rom_nomigrate(flash, NULL,
> hw/mips/mips_malta.c:    memory_region_init_ram_nomigrate(bios_copy,
> NULL, "bios.1fc", BIOS_SIZE,
> hw/net/dp8393x.c:    memory_region_init_ram_nomigrate(&s->prom, OBJECT(dev),
>   [device only used on mips jazz board]
> hw/pci-host/xilinx-pcie.c:    memory_region_init_ram_nomigrate(&s->io,
> OBJECT(s), "io", 16, NULL);
>   [device only used on mips boston board]
> 
> which affect mips boston, malta and jazz boards.
> 
> I don't think we need to fix those first, but:
> 
>  * we should note in the commit message for this patch that
>    it is a de-facto migration break for those boards
>  * we should fix those devices/boards in this release cycle,
>    since we've broken migration compat anyway
>  * we should check with the MIPS maintainers that they're ok
>    with a cross-version migration compat break for those boards
>    (I've cc'd them)

OK, in that case, as long as they're OK, then I think
we should go for it.

Cédric: Were you going to post a version that didn't
do it in set_idstr?

Dave

> thanks
> -- PMM
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK