[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/10] Translate offsets to destination address
Michael R. Hines
Re: [Qemu-devel] [PATCH 04/10] Translate offsets to destination address space
Tue, 19 May 2015 13:57:58 -0500
Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 05/19/2015 01:44 PM, Dr. David Alan Gilbert wrote:
* Michael R. Hines (address@hidden) wrote:
On 04/20/2015 10:57 AM, Dr. David Alan Gilbert (git) wrote:
From: "Dr. David Alan Gilbert" <address@hidden>
The 'offset' field in RDMACompress and 'current_addr' field
in RDMARegister are commented as being offsets within a particular
RAMBlock, however they appear to actually be offsets within the
The code currently assumes that the offsets on the source/destination
match, this change removes the need for the assumption for these
structures by translating the addresses into the ram_addr_t space of
the destination host.
I don't understand fully: If the offsets are not the same, then
why would the RAMBlocks be the same? If a RAMBlock
is hot-plugged on one side, shouldn't an identical one be
hotplugged on the other side, including the offset into ram_addr_t?
If a RAMBlock is hotplugged on the source, it's normally passed in on
the command line at startup on the destination, not hotplugged.
This difference in order of allocation of the RAMBlocks can cause
the allocation of space in ram_addr_t to be different.
In addition changes between qemu versions as to the order in which
devices are initialised can cause differences in the allocation in ram_addr_t.
Indeed the allocation algorithm isn't very deterministic, I think it looks
for the smallest gap that will fit for the allocation.
Also, lets say that you hot plugged 6 devices, and hot unplugged 5,
then migrated; on the destination you only see one of them, not the history
of the other allocations that had to be performed.
I see ---- so until now, I just got "lucky" that the RAMBlocks were
in the same order with the same offsets =).