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 1272417 - qmp didnot distinguish the current work cpu when change the cpu in hmp
Summary: qmp didnot distinguish the current work cpu when change the cpu in hmp
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.2
Hardware: All
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Markus Armbruster
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-16 10:59 UTC by Shuang Yu
Modified: 2016-03-28 09:46 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-26 11:01:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Shuang Yu 2015-10-16 10:59:45 UTC 
Description of problem:
Check the cpu info in qmp and hmp,reassign the cpu in hmp with "(qemu)cpu $i",then check the cpu info in qmp,the qmp cannot distinguish the work cpu for now.

Version-Release number of selected component (if applicable):
kernel-3.10.0-323.el7.ppc64le
qemu-kvm-rhev-2.3.0-30.el7.ppc64le
SLOF-20150313-5.gitc89b0df.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1.Boot the guest:
# /usr/libexec/qemu-kvm -name qmp-auto -machine pseries,accel=kvm,usb=off -realtime mlock=off -nodefaults -monitor stdio -rtc base=utc -drive id=drive_image1,if=none,cache=none,format=raw,file=RHEL-Server-7.2-ppc64le-virtio.raw -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=04,disable-legacy=off,disable-modern=on -m 4096 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -vnc :1 -vga std -msg timestamp=on -usb -device usb-tablet,id=tablet1 -netdev tap,id=hostnet1,script=/etc/qemu-ifup,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:54:5a:5f:54:52 -qmp tcp:0:4444,server,nowait

2.
(qemu) info cpus

3.
{"execute":"query-cpus"}

4.
(qemu) cpu 1
(qemu) info cpus

5.
{"execute":"query-cpus"}

6.
(qemu) cpu 3
(qemu) info cpus

7.
{"execute":"query-cpus"}


Actual results:
After step 2:
(qemu) info cpus
* CPU #0: nip=0xc0000000000946b4 thread_id=33123
  CPU #1: nip=0xc0000000000946b4 thread_id=33124
  CPU #2: nip=0xc0000000000946b4 thread_id=33125
  CPU #3: nip=0xc0000000000946b4 thread_id=33126

After step 3:
{"execute":"query-cpus"}
{"return": [{"current": true, "CPU": 0, "nip": -4611686018426779980, "halted": false, "thread_id": 33123}, {"current": false, "CPU": 1, "nip": -4611686018426779980, "halted": false, "thread_id": 33124}, {"current": false, "CPU": 2, "nip": -4611686018426779980, "halted": false, "thread_id": 33125}, {"current": false, "CPU": 3, "nip": -4611686018426779980, "halted": false, "thread_id": 33126}]}

After step 4:
(qemu) cpu 1
(qemu) info cpus
  CPU #0: nip=0xc0000000000946b4 thread_id=33123
* CPU #1: nip=0xc0000000000946b4 thread_id=33124
  CPU #2: nip=0xc0000000000946b4 thread_id=33125
  CPU #3: nip=0xc0000000000946b4 thread_id=33126

After step 5:
{"return": [{"current": true, "CPU": 0, "nip": -4611686018426779980, "halted": false, "thread_id": 33123}, {"current": false, "CPU": 1, "nip": -4611686018426779980, "halted": false, "thread_id": 33124}, {"current": false, "CPU": 2, "nip": -4611686018426779980, "halted": false, "thread_id": 33125}, {"current": false, "CPU": 3, "nip": -4611686018426779980, "halted": false, "thread_id": 33126}]}

After step 6:
(qemu) cpu 3
(qemu) info cpus
  CPU #0: nip=0xc0000000000946b4 thread_id=33123
  CPU #1: nip=0xc0000000000946b4 thread_id=33124
  CPU #2: nip=0xc0000000000946b4 thread_id=33125
* CPU #3: nip=0xc0000000000946b4 thread_id=33126

After step 7:
{"execute":"query-cpus"}
{"return": [{"current": true, "CPU": 0, "nip": -4611686018426779980, "halted": false, "thread_id": 33123}, {"current": false, "CPU": 1, "nip": -4611686018426779980, "halted": false, "thread_id": 33124}, {"current": false, "CPU": 2, "nip": -4611686018426779980, "halted": false, "thread_id": 33125}, {"current": false, "CPU": 3, "nip": -4611686018426779980, "halted": false, "thread_id": 33126}]}



Expected results:
After the cpu changed by hmp,qmp should recognize the new work cpu,related cpu "current" value should be "true" in qmp query-cpus output.

Additional info:
Retest this issue on x86 platform and hit the same issue.
Comment 3 Markus Armbruster 2015-10-26 11:01:31 UTC 
"Current CPU" is monitor-local, i.e. if you have multiple monitors,
each has its own current CPU.

Therefore, your actual results are expected: executing "cpus" in HMP
(steps 4 and 6) affects "info cpus" in the same monitor, but not
"query-cpus", because that's in a different monitor.

Moreover, only HMP monitors have a current CPU.  QMP command "cpu"
actually does nothing, and command "query-cpus" always shows CPU #0 as
current.  Actually an implementation artifact that shouldn't be relied
on; member "current" exists only for backward compatibility, and
should be ignored.  This mess is due to some confused QMP development
history, and can't be changed now.

Closing NOTABUG.  Please don't hesitate to ask if you have further
questions.
Note You need to log in before you can comment on or make changes to this bug.