qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] migrate: Migration aborts abruptly for machine


From: Ashijeet Acharya
Subject: Re: [Qemu-devel] [PATCH] migrate: Migration aborts abruptly for machine "none"
Date: Sun, 29 Jan 2017 18:49:57 +0530

On Sun, Jan 29, 2017 at 6:33 PM, Greg Kurz <address@hidden> wrote:
> On Sun, 29 Jan 2017 01:06:47 +0530
> Ashijeet Acharya <address@hidden> wrote:
>
>> On Sun, Jan 29, 2017 at 12:11 AM, Greg Kurz <address@hidden> wrote:
>> > On Thu, 26 Jan 2017 14:46:52 +0530
>> > Ashijeet Acharya <address@hidden> wrote:
>> >
>> >> Migration of a "none" machine with no RAM crashes abruptly as
>> >> bitmap_new() fails and thus aborts. Instead, place a check for
>> >> last_ram_offset() being '0' at the start of ram_save_setup() and
>> >> error out with a meaningful error message.
>> >>
>> >> Signed-off-by: Ashijeet Acharya <address@hidden>
>> >> ---
>> >
>>
>> cc'ing Paolo in : I had an IRC chat with him and he has a very
>> interesting twist in the tale to add here.
>>
>> > Maybe a naive question: why a "none" machine with zero RAM should fail to
>> > migrate ?
>>
>> Assuming you are referring to why its failing ATM; it fails because
>
> My question was more: why deciding to fail migration instead of fixing the
> crash ? One would naively think that no RAM is *just* less state to
> migrate... but maybe the current code assumes that a machine always has
> RAM.

Actually, I think, the current code does assume that the machine
always has RAM which is why it crashes here. I am not aware if we can
also boot machines other than 'none'  with zero RAM so I have not
tested that case.
Also, Paolo has a similar opinion to yours that we should fix it
instead of blocking it. He suggests to migrate only the device states
and skip all the RAM related stuff. Maybe he can explain it better
when he is available.

I have had mixed opinions on this one which is why I am waiting until
we reach a common ground.

Ashijeet
>
>> g_try_malloc0() inside bitmap_try_new() returns a NULL pointer for
>> zero bits and thus the check for NULL inside bitmap_new() becomes true
>> and it aborts. Check bitmap_new() for convenience.
>>
>> Ignore the noise if you already knew this! :-)
>>
>
> I hadn't checked, thanks for the details.
>
> Cheers.
>
> --
> Greg
>
>> Ashijeet
>



reply via email to

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