Il 25/11/2013 07:39, Michael R. Hines ha scritto:
>> Because some random option ROM is loaded before the RAM region is
>> created, and thus the ram_addr_t's become misaligned. Keeping the
>> ram_addr_t's aligned in find_ram_offset is easy:
>>
>> diff --git a/exec.c b/exec.c
>> index 79610ce..1b82e81 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -1002,7 +1002,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
>> QTAILQ_FOREACH(block, &ram_list.blocks, next) {
>> ram_addr_t end, next = RAM_ADDR_MAX;
>>
>> - end = block->offset + block->length;
>> + end = ROUND_UP(block->offset + block->length,
>> TARGET_PAGE_SIZE * 64);
>>
>> QTAILQ_FOREACH(next_block, &ram_list.blocks, next) {
>> if (next_block->offset >= end) {
>>
>> but I'm not sure if we're allowed to change the ram_addr_t's. On one
>> hand they
>> are not part of guest ABI, on the other hand RDMA migration uses them
>> in the protocol.
>>
>> Michael, can you check if RDMA migration works from a QEMU *without*
>> this patch to one *with*:
>
> I tested the patch as requested. It doesn't seem to break the migration.
> I compiled and looped the migration a couple of times and it runs through.
>
> Sorry for the late reply.
Thanks, no problem since Juan's patch is 1.8 material anyway.
Juan, looks like I was wrong about the ram_addr_t being part of the
protocol (more likely, it is part of the protocol but it doesn't depend
on equal ram_addr_t). You could then add the above one-liner as a
separate patch.
Paolo
