qemu-devel
[Top][All Lists]
Advanced

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

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


From: Thomas Huth
Subject: Re: [Qemu-devel] migration: QEMU aborts migration of "none" machine
Date: Wed, 25 Jan 2017 17:10:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

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.

 Thomas




reply via email to

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