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

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

[Ashijeet Acharya]

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?

Thanks
Ashijeet

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

[Thomas Huth]

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?

 Thomas

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

[Daniel P. Berrange]

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

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

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

[Juan Quintela]

"Daniel P. Berrange" <berrange@redhat.com> 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?

Later, Juan.

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

[Ashijeet Acharya]

On Wed, Jan 25, 2017 at 4:46 PM, Juan Quintela <quintela@redhat.com> wrote:
> "Daniel P. Berrange" <berrange@redhat.com> 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.

Ashijeet
>
> Later, Juan.

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

[Thomas Huth]

On 25.01.2017 13:58, Ashijeet Acharya wrote:
> On Wed, Jan 25, 2017 at 4:46 PM, Juan Quintela <quintela@redhat.com> wrote:
>> "Daniel P. Berrange" <berrange@redhat.com> 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

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

[Ashijeet Acharya]

On Wed, Jan 25, 2017 at 9:40 PM, Thomas Huth <thuth@redhat.com> wrote:
> On 25.01.2017 13:58, Ashijeet Acharya wrote:
>> On Wed, Jan 25, 2017 at 4:46 PM, Juan Quintela <quintela@redhat.com> wrote:
>>> "Daniel P. Berrange" <berrange@redhat.com> 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
accordingly.

Ashijeet
>  Thomas
>