[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