qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] migration: discard non-migratable RAMBlocks
Date: Wed, 9 May 2018 12:33:09 +0100

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)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]