[Top][All Lists]

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

Re: [Qemu-devel] migration: QEMU aborts migration of "none" machine

From: Ashijeet Acharya
Subject: Re: [Qemu-devel] migration: QEMU aborts migration of "none" machine
Date: Wed, 25 Jan 2017 22:04:53 +0530

On Wed, Jan 25, 2017 at 9:40 PM, Thomas Huth <address@hidden> wrote:
> On 25.01.2017 13:58, Ashijeet Acharya wrote:
>> On Wed, Jan 25, 2017 at 4:46 PM, Juan Quintela <address@hidden> wrote:
>>> "Daniel P. Berrange" <address@hidden> wrote:
>>>> On Wed, Jan 25, 2017 at 11:53:06AM +0100, Thomas Huth wrote:
>>>>> On 25.01.2017 11:01, Ashijeet Acharya wrote:
>>>>>> Hi Thomas,
>>>>>> I was able to reproduce the bug you encountered while trying to migrate
>>>>>> a "none" machine.
>>>>>> After digging deep and debugging the problem with gdb, I found that
>>>>>> bitmap_new() is the function that crashes qemu as it always has
>>>>>> zero bits being passed to it.
>>>>>> I had a discussion with Dave on the IRC yesterday and he suggested the
>>>>>> reason of crash being the absence of RAM ( since machine is "none")
>>>>>> while attempting the migration.
>>>>>> I am not sure what the ideal solution will be in this case; Do any of
>>>>>> the maintainers have any suggestions or even a starting point which I
>>>>>> can ponder upon?
>>>>> I'm not that familiar with the migration code either, but maybe you
>>>>> could simply check for last_ram_offset() == 0 at the beginning of
>>>>> ram_save_setup() and return with an error in that case?
>>>> Do we actually need/want migration to succeed when RAM is 0 or vCPU
>>>> count is 0 ?  If not, then we could just register a migration blocker
>>>> during machine init
>>> Only use that I can see for that is to test that we have setup things
>>> correctly, but for that we could also use an stopped machine.  So, I
>>> don't know if it really makes sense.
>>> If the only problem is that bitmap_new(0) returns 0, we can try to fix
>>> that, no?
>> Yes, bitmap_new(0) aborts in this case. The only way I see to fix this
>> would be to error out rather than simply crashing?
>> Adding a migration blocker is one way too; although I am not aware of
>> the use cases of a "none" machine.
> The "none" machine is - so far - only used for the testing framework
> (see the tests/ directory in the QEMU sources). With the upcoming QEMU
> 2.9, it should also be possible to use it as a simple instruction set
> simulation board. But in both cases, we do not need migration for this
> machine, i.e. simply printing an error message (and refusing to migrate)
> instead of crashing should IMHO be OK here.

Okay, I will write a patch to print an error message and if more
suggestions come during that time, I will make the changes

>  Thomas

reply via email to

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