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

["Cédric Le Goater" <clg@kaod.org>]

Hello David,

On 05/10/2018 09:15 PM, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 9 May 2018 at 12:08, Dr. David Alan Gilbert <dgilbert@redhat.com> 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?

I have a v3, ready to send, adding an error_report() in ram_save_host_page() 
for consistency with the rest of the code. It really should not happen as 
the 'found' bool in ram_find_and_save_block() is protecting the call.

As for setting RAM_MIGRATABLE in vmstate_un/register_ram() instead of 
qemu_ram_un/set_idstr(), yes, I can add this change in v3 also. 
This is not a problem.

C.