[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] migration: discard RAMBlocks of type ram_de
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-devel] [RFC PATCH] migration: discard RAMBlocks of type ram_device |
Date: |
Thu, 12 Apr 2018 09:02:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 04/11/2018 09:21 PM, Dr. David Alan Gilbert wrote:
> * Cédric Le Goater (address@hidden) wrote:
>> Here is some context for this strange change request.
>>
>> On the POWER9 processor, the XIVE interrupt controller can control
>> interrupt sources using MMIO to trigger events, to EOI or to turn off
>> the sources. Priority management and interrupt acknowledgment is also
>> controlled by MMIO in the presenter subengine.
>>
>> These MMIO regions are exposed to guests in QEMU with a set of 'ram
>> device' memory mappings, similarly to VFIO, and the VMAs are populated
>> dynamically with the appropriate pages using a fault handler.
>>
>> But, these regions are an issue for migration. We need to discard the
>> associated RAMBlocks from the RAM state on the source VM and let the
>> destination VM rebuild the memory mappings on the new host in the
>> post_load() operation just before resuming the system.
>>
>> This is the goal of the following proposal. Does it make sense ? It
>> seems to be working enough to migrate a running guest but there might
>> be a better, more subtle, approach.
>
> If this is always true of RAM devices (which I suspect it is).
>
> Interestingly, your patch comes less than 2 weeks after Lai Jiangshan's
> 'add capability to bypass the shared memory'
> https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07511.html
I missed that.
> which is the only other case I think we've got of someone trying to
> avoid transmitting a block.
>
> We should try and merge the two sets to make them consistent; you've
> covered some more cases (the other patch wasn't expected to work with
> Postcopy anyway).
> (At this rate then we can expect another 20 for the year....)
>
> We should probably have:
> 1) A bool is_migratable_block(RAMBlock *)
> 2) A RAMBLOCK_FOREACH_MIGRATABLE(block) macro that is like
> RAMBLOCK_FOREACH but does the call to is_migratable_block
>
> then the changes should be mostly pretty tidy.
yes, indeed, they do.
> A sanity check is probably needed on load as well, to give a neat
> error if for some reason the source transmits pages to you.
OK.
Would a check on the block migratability at the end of function
ram_block_from_stream() be enough ? This is called in ram_load()
and ram_load_postcopy()
> One other thing I notice is your code changes ram_bytes_total(),
> where as the other patch avoids it; I think your code is actually
> more correct.
>
> Is there *any* case in existing QEMUs where we migrate ram devices
> succesfully, if so we've got to make it backwards compatible; but I
> think you're saying there isn't.
The only RAM devices I know of are the VFIOs.
Thanks,
C.