RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1116315 - fail to execute the 'memsave' QMP command in qemu-kvm-rhev-2.0.0
Summary: fail to execute the 'memsave' QMP command in qemu-kvm-rhev-2.0.0
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 7.0
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-04 08:36 UTC by chcheng
Modified: 2016-07-13 18:25 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-31 21:18:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description chcheng 2014-07-04 08:36:11 UTC
Description of problem:
The file can't be created when execute the 'memsave' qmp command. BTW,this issue just hit on qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64, the qemu-kvm-rhev-1.5.3-60.el7ev.x86_64 works well.

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm-rhev
3.10.0-126.el7.x86_64
qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64
guest info:
# uname -r
3.10.0-126.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot with QMP enabled like:...-qmp tcp:0:4444,server
2.from any box with telnet client
run #telnet $HostIP 4444
3.query the memsave command existing in QMP.
{"execute": "qmp_capabilities"}
{"return": {}}
{"execute": "query-commands"}
{"return": [...{"name": "pmemsave"}, {"name": "memsave"}...]}
4.execute the memsave commands as following.
  ","arguments":{"val":1,"size":655350000,"filename":"test"}}

Actual results:
After step 4,
{"error": {"class": "GenericError", "desc": "Invalid addr 0x0000000000000001specified"}}

Expected results:
After step 4,the message shall like the following: {"return": {}}, and the file is created with the request size.

Additional info:

Comment 2 juzhang 2014-07-08 07:20:23 UTC
Limit the group to Red Hat Employee (internal) since qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64 is internal test build.

Comment 5 Cole Robinson 2014-07-08 18:37:50 UTC
Can you provide a full qemu command line that reproduces? This doesn't trivially reproduce for me at least

Comment 6 chcheng 2014-07-10 04:44:02 UTC
(In reply to Cole Robinson from comment #5)
> Can you provide a full qemu command line that reproduces? This doesn't
> trivially reproduce for me at least
Hi Cole Robinson,

My qemu-kvm cmdline is as following.
# /usr/libexec/qemu-kvm -M pc -cpu host -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name chcheng -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,bus=pci.0,addr=0x5,bootindex=2 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :2 -spice disable-ticketing,port=5931 -monitor stdio -drive file=/home/cccc.2,if=none,id=drive-virtio0-0-0,media=disk,werror=stop,rerror=stop,cache=none,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio0-0-0,id=virtio0-0-0,bootindex=0

QMP:
{"execute": "qmp_capabilities"}
{"return": {}}
{"execute":"memsave","arguments":{"val":1,"size":655350000,"filename":"aaaa"}}
{"error": {"class": "GenericError", "desc": "Invalid addr 0x0000000000000001specified"}}

host info:
# uname -r && rpm -q qemu-kvm-rhev
3.10.0-126.el7.x86_64
qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64
guest info:
# uname -r
3.10.0-126.el7.x86_64

Best Regards,
chcheng

Comment 7 Cole Robinson 2014-10-09 19:57:39 UTC
Okay, I can reproduce. Using this more stripped down command line:

./x86_64-softmmu/qemu-system-x86_64 -m 2048 \
    -smp 2,sockets=2,cores=1,threads=1 \
    -netdev user,id=hostnet0 \
    -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,bus=pci.0,addr=0x5,bootindex=2 \
    -drive file=/mnt/data/devel/images/f20.qcow2,if=none,id=drive-virtio0-0-0,media=disk,werror=stop,rerror=stop,cache=none,format=qcow2 \
    -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio0-0-0,id=virtio0-0-0,bootindex=0 \
    -display none \
    -monitor stdio

And this monitor command:

  memsave 0 655350000 aaaa

You need to wait for the guest to actually leave the bios and start booting before the failure pops up.

The error message was added with this commit:

commit 2f4d0f5990ede025720e41fa473029e9ca85e8b8
Author: Aneesh Kumar K.V <aneesh.kumar.ibm.com>
Date:   Tue Oct 1 21:49:30 2013 +0530

    target-ppc: Check for error on address translation in memsave command
    
    When we translate the virtual address to physical check for error.

Which seems reasonable.

The API is only exposed as virDomainMemoryPeek by libvirt, however none of the desktop tools use that, nor vdsm, and I don't think openstack does either.

And the thing is, I don't really know how memsave is expected to be used, or even how to verify that it's output is 'working'. So I don't know how to tell if the error message is a legitimate error condition, or something that can be worked around.

chcheng, is this part of a qe test suite? do you just check to see that the API succeeds, or is the memory output analyzed in any way?

Comment 8 Cole Robinson 2014-10-09 20:00:58 UTC
Should have also mentioned, I reproduce with qemu.git as well

Comment 9 Sibiao Luo 2014-10-10 08:34:41 UTC
(In reply to Cole Robinson from comment #7)
> 
> The API is only exposed as virDomainMemoryPeek by libvirt, however none of
> the desktop tools use that, nor vdsm, and I don't think openstack does
> either.
> 
> And the thing is, I don't really know how memsave is expected to be used, or
> even how to verify that it's output is 'working'. So I don't know how to
> tell if the error message is a legitimate error condition, or something that
> can be worked around.
> 
chcheng is on leave, so i help to reply her needinfo.

> chcheng, is this part of a qe test suite? do you just check to see that the
> API succeeds, or is the memory output analyzed in any way?
Right, we have such test scenario/plan reviewed by QMP feature developer and we just check the QMP API to make sure it succeeds, not concerned about the memory output analyzed from KVM QE view. Please correct me if any mistake, thanks in advance.

Best Regards,
sluo

Comment 11 Cole Robinson 2014-11-17 20:49:54 UTC
Since this isn't actually required by RHEV or any common usages of libvirt, it's really only affecting an arbitrary QE test case, and it's not obvious to me if qemu is even wrong in erroring here, I don't think this should be a 7.1 blocker. Deferring to 7.2

Comment 15 Cole Robinson 2015-08-10 23:50:22 UTC
(In reply to Cole Robinson from comment #11)
> Since this isn't actually required by RHEV or any common usages of libvirt,
> it's really only affecting an arbitrary QE test case, and it's not obvious
> to me if qemu is even wrong in erroring here, I don't think this should be a
> 7.1 blocker. Deferring to 7.2

Same still applies. Given that none of the tools even need this functionality I think we can safely close this for RHEL7, but since I don't really understand the underlying issue maybe it's just another bug lying in wait. Dunno...

Comment 16 Karen Noel 2015-08-29 02:10:40 UTC
Too late for 7.2, move to 7.3.

Cole, If you can reproduce it, maybe you should just fix it upstream and we'll get it on the next rebase.

Or, if you really don't think it is important, then just close it. Thanks!

Comment 18 Cole Robinson 2015-08-31 21:18:08 UTC
(In reply to Karen Noel from comment #16)
> 
> Cole, If you can reproduce it, maybe you should just fix it upstream and
> we'll get it on the next rebase.
> 
> Or, if you really don't think it is important, then just close it. Thanks!

Comment #7 still applies... I don't know enough about this space to know if the 'regression' here is even an error or not, it seems plausible it's intentional. But since no higher level tools actually need this function to work, let's just close this

Comment 19 Markus Armbruster 2016-06-16 06:15:24 UTC
Re comment#7: the upstream commit message quoted there is annoyingly
misleading.

1. This isn't about target-ppc.  It's perfectly generic code.  All
targets are affected.

2. This isn't about translating virtual address to physical.  The
command saves *physical* memory, as seen by a specific CPU, by default
cpu 0.

One error per phrase, promising contestant for the "confuser of the
week" contest.

Can't say why memsave's idea of the CPU's physical memory changes
during boot.

Comment 20 Markus Armbruster 2016-06-16 06:18:55 UTC
Correction: I got confused.  The command to save physical memory is pmemsave.  memsave saves virtual memory.  So the error is indeed about virtual-to-physical address translation, and the fact that it changes during boot is not surprising.


Note You need to log in before you can comment on or make changes to this bug.