Bug 1160964 - can boot guest successfully inside qemu if maxcpus don't match topology in -smp
Summary: can boot guest successfully inside qemu if maxcpus don't match topology in -smp
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Eduardo Habkost
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-06 03:27 UTC by Lin Chen
Modified: 2016-11-07 20:16 UTC (History)
10 users (show)

Fixed In Version: qemu-kvm-rhev-2.6.0-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-07 20:16:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Lin Chen 2014-11-06 03:27:46 UTC
Description of problem:
can boot guest successfully inside qemu if maxcpus don't match topology:
"-smp x,cores=a,thread=b,socket=c,maxcpus=y" (y>x and a*b*c=y)


Version-Release number of selected component (if applicable):
 uname -r
  3.10.0-195.el7.x86_64
 rpm -qa|grep qemu
  qemu-kvm-rhev-2.1.2-5.el7.x86_64


How reproducible:
100%


Steps to Reproduce:
1.boot guest with command:
 /usr/libexec/qemu-kvm -smp 3,cores=1,threads=1,sockets=1,maxcpus=8


Actual results:
boot guest successfully

Expected results:
fail to boot guest.
it's not possible to have more than 1 cpu with sockets=1,cores=1,threads=1, topology must match maxcpus.

Additional info:

Comment 2 Eduardo Habkost 2014-11-06 13:43:07 UTC
(In reply to Lin Chen from comment #0)
> Steps to Reproduce:
> 1.boot guest with command:
>  /usr/libexec/qemu-kvm -smp 3,cores=1,threads=1,sockets=1,maxcpus=8

This is invalid configuration. QEMU can reject it in the future, but it is not a bug.

Comment 3 Andrew Jones 2014-11-06 16:14:37 UTC
This BZ got me looking at smp_parse(), and there are a couple issues. I just sent a patch upstream for them.

Here are some tests that expose the issues I saw

# The topology doesn't necessarily support up to max_cpus
-smp 4,sockets=2,maxcpus=8  sockets=2 cores=2 threads=1 smp_cpus=4 max_cpus=8

# If the topology supports more than smp_cpus, then max_cpus should be higher
-smp 4,sockets=4,cores=2     sockets=4 cores=2 threads=1 smp_cpus=4 max_cpus=4

# smp_parse() shouldn't silently adjust the number of threads
-smp 4,sockets=1,cores=2,threads=1  sockets=1 cores=2 threads=2 smp_cpus=4 max_cpus=4
-smp 4,sockets=2,cores=2,threads=4,maxcpus=8  sockets=2 cores=2 threads=1 smp_cpus=4 max_cpus=8

Comment 4 Andrew Jones 2014-11-06 16:17:38 UTC
(In reply to Andrew Jones from comment #3)
> This BZ got me looking at smp_parse(), and there are a couple issues. I just
> sent a patch upstream for them.
> 
> Here are some tests that expose the issues I saw

And what I think the results should be

> 
> # The topology doesn't necessarily support up to max_cpus
> -smp 4,sockets=2,maxcpus=8  sockets=2 cores=2 threads=1 smp_cpus=4 max_cpus=8
                                              ^ should be 4       
> 
> # If the topology supports more than smp_cpus, then max_cpus should be higher
> -smp 4,sockets=4,cores=2     sockets=4 cores=2 threads=1 smp_cpus=4
> max_cpus=4
           ^ should be 8
> 
> # smp_parse() shouldn't silently adjust the number of threads
> -smp 4,sockets=1,cores=2,threads=1  sockets=1 cores=2 threads=2 smp_cpus=4
> max_cpus=4
> -smp 4,sockets=2,cores=2,threads=4,maxcpus=8  sockets=2 cores=2 threads=1
> smp_cpus=4 max_cpus=8

These both should cause qemu to exit with some error messages.

Comment 5 Lin Chen 2014-11-07 02:05:55 UTC
>/usr/libexec/qemu-kvm -smp 3,cores=1,threads=1,sockets=1,maxcpus=8
> This is invalid configuration. QEMU can reject it in the future, but it is
> not a bug.

Indeed,it is invalid configuration.So QEMU shouldn't allow it,because if boot guest with this configuration successfully guest will get 3 cpus but 1 core,1 thread and 1 socket.Isn't it a potential issue?

Comment 6 Eduardo Habkost 2014-11-10 14:17:22 UTC
(In reply to Lin Chen from comment #5)
> >/usr/libexec/qemu-kvm -smp 3,cores=1,threads=1,sockets=1,maxcpus=8
> > This is invalid configuration. QEMU can reject it in the future, but it is
> > not a bug.
> 
> Indeed,it is invalid configuration.So QEMU shouldn't allow it,because if
> boot guest with this configuration successfully guest will get 3 cpus but 1
> core,1 thread and 1 socket.Isn't it a potential issue?

It is a potential issue, but the solution (until we implement the extra checks) is very simple: just don't run QEMU with an invalid configuration.

Comment 10 Eduardo Habkost 2016-06-23 23:01:44 UTC
Should be fixed in the 2.6 rebase.

Comment 11 Guo, Zhiyi 2016-09-12 06:01:19 UTC
Test against qemu-kvm-rhev-2.6.0-22.el7.x86_64:

case 1:
# /usr/libexec/qemu-kvm -smp 3,cores=1,threads=1,sockets=1,maxcpus=8
qemu-kvm: cpu topology: sockets (1) * cores (1) * threads (1) < smp_cpus (3)

case 2:
# /usr/libexec/qemu-kvm -smp 4,sockets=2,cores=2,threads=4,maxcpus=8
qemu-kvm: cpu topology: sockets (2) * cores (2) * threads (4) > maxcpus (8)

case 3:
# /usr/libexec/qemu-kvm -smp 4,sockets=1,cores=2,threads=1
qemu-kvm: cpu topology: sockets (1) * cores (2) * threads (1) < smp_cpus (4)

Comment 12 Guo, Zhiyi 2016-09-12 06:11:04 UTC
case 4:
# /usr/libexec/qemu-kvm -smp 4,sockets=2,cores=2,threads=1,maxcpus=8 -monitor stdio
QEMU 2.6.0 monitor - type 'help' for more information
(qemu) VNC server running on '::1;5900'

Hi Eduardo,

Could you help to check whether qe can verify this bug? Thanks!

BR/
Guo,Zhiyi

Comment 13 Eduardo Habkost 2016-09-12 14:40:20 UTC
(In reply to Guo, Zhiyi from comment #12)
> case 4:
> # /usr/libexec/qemu-kvm -smp 4,sockets=2,cores=2,threads=1,maxcpus=8
> -monitor stdio
> QEMU 2.6.0 monitor - type 'help' for more information
> (qemu) VNC server running on '::1;5900'
> 

This is expected. As "sockets" is used to calculate cores/threads automatically based on "cpus" only, not "maxcpus" (when socket and/or cores are omitted), we only ensure cpus <= (socket * cores * threads) <= maxcpus. Note that "sockets" is completely ignored when both "cores" and "threads" are specified, anyway, so this is just a sanity check to see if the requested configuration makes sense.

Comment 14 Guo, Zhiyi 2016-09-13 01:55:34 UTC
Move to verified per comment 11-13

Comment 16 errata-xmlrpc 2016-11-07 20:16:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html


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