qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 3/6] rdma: core logic
Date: Fri, 28 Jun 2013 15:07:16 +0100

On 28 June 2013 15:00, Michael R. Hines <address@hidden> 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.)

>>   * 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).

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]