* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote: > On 05/19/2015 01:44 PM, Dr. David Alan Gilbert wrote: > >* Michael R. Hines (mrhi...@linux.vnet.ibm.com) wrote: > >>On 04/20/2015 10:57 AM, Dr. David Alan Gilbert (git) wrote: > >>>From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > >>> > >>>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 > >>>ram_addr_t space. > >>> > >>>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 =).
Yep. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
