Bug 1434276 - virsh vcpupin shows the wrong cpu affinity details
Summary: virsh vcpupin shows the wrong cpu affinity details
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: ppc64le
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks: PPCTracker 1480062
TreeView+ depends on / blocked
 
Reported: 2017-03-21 07:10 UTC by Satheesh Rajendran
Modified: 2019-01-13 12:37 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-03-21 07:24:34 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 174632 None None None 2019-06-25 16:58 UTC

Description Satheesh Rajendran 2017-03-21 07:10:46 UTC
Description of problem:
Boot the vm and check virsh vcpupin output, it does shows the affinity with offline cpus(host) aswell.

Version-Release number of selected component (if applicable):
# virsh version
Compiled against library: libvirt 3.2.0
Using library: libvirt 3.2.0
Using API: QEMU 3.2.0
Running hypervisor: QEMU 2.8.50

libvirt compiled against
commit a6d681485ff85e27859583a5c20e1630c5cf8352
Author: John Ferlan <jferlan@redhat.com>
Date:   Tue Mar 7 16:10:38 2017 -0500

qemu compiled againt
commit ebedf0f9cd46b617df331eecc857c379d574ac62
Author: Marek Vasut <marex@denx.de>
Date:   Fri Mar 17 22:06:27 2017 +0100


How reproducible:
Always

Steps to Reproduce:
1. # virsh start vm1
Domain vm1 started

2. # lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                160
On-line CPU(s) list:   0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152
Off-line CPU(s) list:  1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79,81-87,89-95,97-103,105-111,113-119,121-127,129-135,137-143,145-151,153-159
Thread(s) per core:    1
Core(s) per socket:    5
Socket(s):             4
NUMA node(s):          4
Model:                 2.1 (pvr 004b 0201)
Model name:            POWER8E (raw), altivec supported
L1d cache:             64K
L1i cache:             32K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0,8,16,24,32
NUMA node1 CPU(s):     40,48,56,64,72
NUMA node16 CPU(s):    80,88,96,104,112
NUMA node17 CPU(s):    120,128,136,144,152

2. virsh vcpuinfo vm1
VCPU:           0
CPU:            48
State:          running
CPU time:       27.3s
CPU Affinity:   y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------y-------
                  -----------[OK]
# virsh vcpupin vm1
VCPU: CPU Affinity
----------------------------------
   0: 0-159----------------------------------[NOK]

3.

Actual results:
0: 0-159

Expected results:
0: 0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152

Additional info:

Comment 1 Peter Krempa 2017-03-21 07:24:34 UTC
Since you did not configure any specific vcpu pinning, the vcpu threads are allowed to run on all the host vcpus from libvirt's point of view.

Returning the value expected by you would indicate that there's a pinning configured which is not true.

Comment 2 Satheesh Rajendran 2017-03-21 07:41:46 UTC
(In reply to Peter Krempa from comment #1)
> Since you did not configure any specific vcpu pinning, the vcpu threads are
> allowed to run on all the host vcpus from libvirt's point of view.
> 
> Returning the value expected by you would indicate that there's a pinning
> configured which is not true.

I agree partially but it can not be run on a offlined cpu which is in this case needs a proper initial value, it shows the invalid initial range for the user which is wrong whereas vcpuinfo API output is as expected.

#virsh vcpupin vm1 0 1
error: Invalid value '1' for 'cpuset.cpus': Invalid argument --------------OK

but the initial output range of affinity "0-159" contradicts that.

Comment 3 srwx4096 2017-03-28 13:35:21 UTC
This seems to me yet another design decision issue, of course it can be 'fixed', but do we want it fixed?

Again, I am just trying to contribute some code. 

Dan

Comment 4 Nitesh Konkar 2017-04-17 08:01:02 UTC
(In reply to srwx4096 from comment #3)
> This seems to me yet another design decision issue, of course it can be
> 'fixed', but do we want it fixed?
> 
> Again, I am just trying to contribute some code. 
> 
> Dan

Hi Dan,

I think this should be fixed because as pointed out by Viktor, CPU hotplug is very common on Linux running on z Systems and also widely used by customers.

Reference: https://www.spinics.net/linux/fedora/libvir/msg140443.html

Hence if a host CPU is offline and virsh cpupin/emulatorpin shows them as available for pinning, this would mislead user/other layers which shall end up in trying wrong pinning and fail.

-Nitesh

Comment 5 Satheesh Rajendran 2017-05-04 05:29:50 UTC
Any update on this?


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