Re: [Qemu-devel] [PATCH 3/6] rdma: core logic

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 06/28/2013 10:07 AM, Peter Maydell wrote:
> On 28 June 2013 15:00, Michael R. Hines <mrhines@linux.vnet.ibm.com> wrote:
>> On 06/28/2013 09:28 AM, Peter Maydell wrote:
>>>> Is endianess for the data a big issue when you are assume the migration
>>>> is happening across identical CPU architectures?
>>> Well:
>>>    * is that a reasonable assumption? (why?)
>>
>> I would yes, because we're dealing raw guest RAM.
>> Migration of memory would not work across a different architecture
>> (particularly page tables - which would need to be canonicalized
>> and de-canonicalized).
> Raw guest RAM is fine, because the VM at the destination
> will (by definition) be running a guest of the same endianness.
> However it looks like in this code you have host (QEMU)
> code looking into the guest RAM, and the guest and host
> might not have the same endianness. (The easy way for them
> to be different is if you're using TCG rather than KVM;
> alternatively you might be running a big-endian VM inside KVM
> with a little-endian QEMU controlling it, if your architecture
> supports that.)

Alright, I see. I guess the moral of the story is that I should
not make any architecture assumptions about *any* part
of QEMU, then.

I'll add the remaining byte-swap routines for safety to the
patch before I sent out the next patch series.

>>>    * if you try this on some setup where it's not true, do we
>>>      fail helpfully or obscurely?
>> Shouldn't a check like that occur before the migration actually begins?
>> Is this specific to RDMA?
> Normal migration works fine for TCG because it doesn't depend on
> the endianness of the host vs the guest -- everything on the
> wire is in big-endian format and we byteswap field values as
> we marshall them. Guest RAM itself is just sent as a bag of bytes
> (conceptually speaking, anyway).

Understood.

- Michael