Bug 1160964
Summary: | can boot guest successfully inside qemu if maxcpus don't match topology in -smp | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Lin Chen <linchen> |
Component: | qemu-kvm-rhev | Assignee: | Eduardo Habkost <ehabkost> |
Status: | CLOSED ERRATA | QA Contact: | Guo, Zhiyi <zhguo> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7.1 | CC: | ailan, drjones, ehabkost, hhuang, huding, juzhang, michen, virt-maint, xfu, zhguo |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-rhev-2.6.0-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-07 20:16:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lin Chen
2014-11-06 03:27:46 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. 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 (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. >/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?
(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. Should be fixed in the 2.6 rebase. 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) 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 (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. Move to verified per comment 11-13 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 |