[Qemu-devel] [PATCH RFC 0/1] vmstate: fix the failed iotests case 68 and 91

QingFeng Hao posted 1 patch 7 years, 1 month ago
Failed in applying to current master (apply log)
migration/vmstate.c | 8 ++++++++
1 file changed, 8 insertions(+)
[Qemu-devel] [PATCH RFC 0/1] vmstate: fix the failed iotests case 68 and 91
Posted by QingFeng Hao 7 years, 1 month ago
Hi All,
I am not sure if the fix is correct because I am not very clear about the
logic in vmstate.c. From my test, once size=0, the iotests case 68 failed
due to the assert. So just send this draft patch for your comments!
The patch is based on commit 17783ac828a "Merge remote-tracking branch
'remotes/dgibson/tags/ppc-for-2.9-20170303' into staging".
Thanks!

QingFeng Hao (1):
  vmstate: fix the failure of iotests cases 68 and 91

 migration/vmstate.c | 8 ++++++++
 1 file changed, 8 insertions(+)

-- 
2.8.4


Re: [Qemu-devel] [PATCH RFC 0/1] vmstate: fix the failed iotests case 68 and 91
Posted by Fam Zheng 7 years, 1 month ago
On Tue, 03/07 03:53, QingFeng Hao wrote:
> Hi All,
> I am not sure if the fix is correct because I am not very clear about the
> logic in vmstate.c. From my test, once size=0, the iotests case 68 failed
> due to the assert. So just send this draft patch for your comments!
> The patch is based on commit 17783ac828a "Merge remote-tracking branch
> 'remotes/dgibson/tags/ppc-for-2.9-20170303' into staging".

I cannot reproduce the failure on either 17783ac828a or current head
56b51708e9e. Both passes for me. I wonder where do you get the size=0.

Fam

Re: [Qemu-devel] [PATCH RFC 0/1] vmstate: fix the failed iotests case 68 and 91
Posted by QingFeng Hao 7 years, 1 month ago

在 2017/3/7 14:37, Fam Zheng 写道:
> On Tue, 03/07 03:53, QingFeng Hao wrote:
>> Hi All,
>> I am not sure if the fix is correct because I am not very clear about the
>> logic in vmstate.c. From my test, once size=0, the iotests case 68 failed
>> due to the assert. So just send this draft patch for your comments!
>> The patch is based on commit 17783ac828a "Merge remote-tracking branch
>> 'remotes/dgibson/tags/ppc-for-2.9-20170303' into staging".
> I cannot reproduce the failure on either 17783ac828a or current head
> 56b51708e9e. Both passes for me. I wonder where do you get the size=0.
The error happens when running "savevm 0" in case 068. It can be 
manually reproduced
by "./check -qcow2 68" or "./s390x-softmmu/qemu-system-s390x -nodefaults \
-machine accel=qtest -no-shutdown -nographic -monitor stdio -serial none \
-hda /home/mc/gitcheck/work/qemu-master/tree/qemu/tests/t.img.bak", then 
type
"savevm 0".  t.img.bak is the backup image for t.img generated by 068.

I added the print in vmstate_save_state:
    QJSON *vmdesc_loop = vmdesc;
+ error_report("haoqf:%s:opaque:%p, offset:%lx, size:%d, field name:%s, 
vname:%s\n", __FUNCTION__, opaque, field->offset, size, field->name, 
vmsd->name);

And here is the test log:
haoqf:vmstate_save_state:opaque:0x2aa5a5715c0, offset:122e1, size:1, 
field name:env.sigp_order, vname:cpu

haoqf:vmstate_size: field size:4, offset:0

haoqf:vmstate_save_state:opaque:0x2aa5a5715c0, offset:12300, size:4, 
field name:irqstate_saved_size, vname:cpu

haoqf:vmstate_size: field size:0, offset:74496

haoqf:vmstate_size: calculated size:0

haoqf:vmstate_save_state:opaque:0x2aa5a5715c0, offset:122f8, size:0, 
field name:irqstate, vname:cpu

haoqf:vmstate_save_state:firstelem:(nil), elements: 1

qemu-system-s390x: ../migration/vmstate.c:336: vmstate_save_state: 
Assertion `first_elem || !n_elems' failed.
Aborted (core dumped)

I also did the test for x86 with: "./x86_64-softmmu/qemu-system-x86_64 
-nodefaults \
-machine accel=qtest -no-shutdown -nographic -monitor stdio -serial none \
-hda /home/mc/gitcheck/work/qemu-master/tree/qemu/tests/t.img.bak",
and then ran "savevm 0", but it didn't core and the size are all non-zero:
haoqf:vmstate_save calling vmstate_save_state:

haoqf:vmstate_size: field size:4, offset:0

haoqf:vmstate_save_state:opaque:0x2aa13325438, offset:4, size:4, field 
name:size, vname:globalstate

haoqf:vmstate_size: field size:100, offset:0

haoqf:vmstate_save_state:opaque:0x2aa13325438, offset:8, size:100, field 
name:runstate, vname:globalstate

haoqf:vmstate_save:called vmstate_save_state

So probably x86 doesn't have this problem.
> Fam
>

-- 
Regards
QingFeng Hao