Description of problem: Cores and sockets argument can be set to negative number Version-Release number of selected component (if applicable): host:3.10.0-748.el7.ppc64le qemu-kvm-rhev-2.10.0-13.el7.ppc64le How reproducible: Steps to Reproduce: 1.Boot gues with command -smp 1,cores=-1,threads=1,sockets=-1 2. 3. Actual results: Can boot up successfully. Expected results: Cann't boot up successfully,should give some warning msg. Additional info:
On x86,have different result.qemu quit with error below: qemu-kvm: /builddir/build/BUILD/qemu-2.10.0/target/i386/cpu.c:2979: cpu_x86_cpuid: Assertion `!(*eax & ~0x1f)' failed. vm.sh: line 18: 5455 Aborted /usr/libexec/qemu-kvm -smp 1,sockets=-1,cores=-1,threads=1 -m 8192,slots=4,maxmem=32G -object memory-backend-file,mem-path=/mnt/kvm_hugepage,size=256M,id=mem-hugepage -device pc-dimm,id=dimm-hugepage,memdev=mem-hugepage -vnc :59 -device nec-usb-xhci,id=xhci -device usb-hub,id=hub,port=2 -device virtio-scsi-pci,bus=pci.0 -device scsi-hd,id=scsi-hd0,drive=scsi-hd0-dr0,bootindex=0 -drive file=rhel-guest-image-7.5-48.x86_64.qcow2,if=none,id=scsi-hd0-dr0,format=qcow2,cache=none -nographic -chardev stdio,mux=on,id=serial0,server,nowait -device isa-serial,chardev=serial0,id=serial0 -mon chardev=serial0,mode=readline -nodefaults -boot menu=on
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Eduardo, IIUC, this isn't really ppc related. It's just that x86 happens to hit an abort() pretty early in this bogus situation, whereas power does not. Given that, can we change Hardware to All? At the moment this is (IMO, erroneously) showing up on searches I'm making to look for bugs relevant to me I might have missed.
(In reply to David Gibson from comment #8) > Eduardo, > > IIUC, this isn't really ppc related. It's just that x86 happens to hit an > abort() pretty early in this bogus situation, whereas power does not. > > Given that, can we change Hardware to All? At the moment this is (IMO, > erroneously) showing up on searches I'm making to look for bugs relevant to > me I might have missed. Done. Thanks for noticing, and sorry for taking so long to reply.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Can't trigger from libvirt side. <topology sockets='-1' cores='-1' threads='1'/> error: unsupported configuration: cpu topology results in more than 4294967295 cpus