Bug 745047 - qemu-kvm fails to deal with invalid -smp option properly
qemu-kvm fails to deal with invalid -smp option properly
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Eduardo Habkost
Virtualization Bugs
:
: 852642 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-11 05:38 EDT by Shaolong Hu
Modified: 2014-07-24 16:48 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-24 16:46:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Shaolong Hu 2011-10-11 05:38:01 EDT
Description of problem:
------------------------
When specify -smp [,cores=cores][,threads=threads][,sockets=sockets], qemu-kvm drops following options encountering first invalid option, which means "-smp sdf,cores=2" will be treat as default, and "-smp cores=2,sdf" will be treat as "-smp cores=2", this causes same typo with different sequence giving guest different cpu topology, and there is no error prompt, it's hard to diagnose.

Version-Release number of selected component (if applicable):
----------------------------------------------------------------
qemu-kvm-0.12.1.2-2.195.el6.x86_64

How reproducible:
------------------
100%

Steps to Reproduce:
--------------------
1.boot guest with "-smp sdf,cores=2", then "-smp cores=2,sdf", compare cpu topology in guest.

2.to further testify this, add [,threads=threads][,sockets=sockets], change anyone to a invalid value.


Expected results:
------------------
The simplest way is to quit qemu-kvm when encountering invalid -smp option.

Additional info:
------------------
Should be mentioned, due to bug 689665, cpu topology may be not correct when reproduce this, please ignore it.
Comment 1 Chao Yang 2011-10-13 01:13:17 EDT
An update with qemu-kvm-0.12.1.2-2.196.el6.x86_64:
 -smp dd,cores=2,dd,sockets=2,threads=2
 (qemu) info cpus
 * CPU #0: pc=0x00000000000c945c (halted) thread_id=13833 
   CPU #1: pc=0x00000000000ff0a2 (halted) thread_id=13834 
 -smp dd,cores=2,sockets=2,threads=2
 (qemu) info cpus
 * CPU #0: pc=0x00000000000fe4ee thread_id=13798 
   CPU #1: pc=0x00000000000ff0a2 (halted) thread_id=13799 
   CPU #2: pc=0x00000000000ff0a2 (halted) thread_id=13800 
   CPU #3: pc=0x00000000000ff0a2 (halted) thread_id=13801
Comment 2 Shaolong Hu 2011-10-13 01:36:18 EDT
(In reply to comment #1)
> An update with qemu-kvm-0.12.1.2-2.196.el6.x86_64:
>  -smp dd,cores=2,dd,sockets=2,threads=2
>  (qemu) info cpus
>  * CPU #0: pc=0x00000000000c945c (halted) thread_id=13833 
>    CPU #1: pc=0x00000000000ff0a2 (halted) thread_id=13834 
>  -smp dd,cores=2,sockets=2,threads=2
>  (qemu) info cpus
>  * CPU #0: pc=0x00000000000fe4ee thread_id=13798 
>    CPU #1: pc=0x00000000000ff0a2 (halted) thread_id=13799 
>    CPU #2: pc=0x00000000000ff0a2 (halted) thread_id=13800 
>    CPU #3: pc=0x00000000000ff0a2 (halted) thread_id=13801

Ok, seems there is no regular pattern.
Comment 3 Ademar Reis 2011-12-09 11:40:18 EST
Discussed with Eduardo in PVT and we concluded this should be fixed in rhel-7 and not 6.3. Users are supposed to be using libvirt instead of qemu-kvm directly, so this is minor.
Comment 4 Ademar Reis 2012-09-07 16:29:05 EDT
*** Bug 852642 has been marked as a duplicate of this bug. ***
Comment 5 Ademar Reis 2012-09-07 16:30:44 EDT
(In reply to comment #4)
> *** Bug 852642 has been marked as a duplicate of this bug. ***

Interesting analysis from Markus Armbruster over there:

"""
Yes, parsing of -smp's argument is sloppy.  Same upstream.

-help claims number of CPUs is mandatory, but the code treats it as optional.

Additional funnies:

* -smp ""
  Since all parameters are optional, this has no effect

* -smp 0
  Code interprets 0 as "use default", and the default is 1.

  Same for all the named parameter values.

* -smp 4294967296

  Argument is silently truncated to int, in this case to zero.

* -smp 1,sockets=

  Named parameter with empty value is silently ignored.

* -smp 1,sockets=maybe

  Named parameter value is parsed just as sloppily as the number of CPUs, in this case as zero.

* -smp 1,silly
  -smp 1,qemu=moron

  Unknown parameters are silently ignored.
"""
Comment 12 Eduardo Habkost 2014-07-24 16:47:20 EDT
Upstream fix is:

commit 12b7f57e2cfcd665cf5a21b4ae3c23b9361c5c05
Author: Michael Tokarev <mjt@tls.msk.ru>
Date:   Mon Jun 24 15:06:52 2013 +0400

    vl: convert -smp to qemu_opts_parse()
    
    This also introduces a new suboption, "cpus=",
    which is the default.  So after this patch,
    
     -smp n,sockets=y
    
    is the same as
    
      -smp cpus=n,sockets=y
    
    (with "cpu" being some generic thing, referring to
    either cores, or threads, or sockets, as before).
    
    We still don't validate relations between different
    numbers, for example it is still possible to say
    
      -smp 1,sockets=10
    
    and it will be accepted to mean sockets=1.
    
    Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
    Message-id: 1372072012-30305-1-git-send-email-mjt@msgid.tls.msk.ru
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

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