11:45 a.m.
The man page of qemu(2.6.2), states the following:
-smp
[cpus=]n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]
Simulate an SMP system with n CPUs. On the PC target, up to 255
CPUs are supported. On Sparc32 target, Linux limits the number of usable
CPUs to 4. For the PC target, the number of cores per
socket, the number of threads per cores and the total number of
sockets can be specified. Missing values will be computed. *If any on the
three values is given, the total number of CPUs n can be
omitted*. maxcpus specifies the maximum number of hotpluggable
CPUs.
So, I built the master branch of libvirt and tested the following:
Client:
$ ./run ./tools/virsh domxml-from-native qemu-argv <(echo
'/usr/bin/qemu-system-x86_64 -enable-kvm -smp cores=2,threads=1,sockets=1')
error: Disconnected from qemu:///session due to I/O error
error: Cannot recv data: Connection reset by peer
Server:
$ ./run gdb ./daemon/libvirtd
GNU gdb (GDB) Fedora 7.11.1-86.fc24
...
Starting program: /home/wani/libvirt/daemon/.libs/lt-libvirtd
[Thread debugging using libthread_db enabled]
...
[Thread 0x7fffc462c700 (LWP 16850) exited]
...
Thread 4 "lt-libvirtd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe4cf1700 (LWP 16836)]
qemuDomainDefVcpusPostParse (def=0x7fffb8000ec0) at qemu/qemu_domain.c:2480
2480 if (!vcpu->online) {
qemuDomainDefVcpusPostParse() calls vcpu = virDomainDefGetVcpu(def, 0),
which returns NULL.
I'd be happy to send a patch, but I am not sure what the right solution is.
- Should not specifying n to -smp allowed?
- Should -cpus=n also be parsed in qemuParseCommandLineSmp()?
Cheers!
Nehal J Wani
2:50 a.m.
On Sun, Nov 13, 2016 at 11:15:29PM +0530, Nehal J Wani wrote:
The man page of qemu(2.6.2), states the following:
-smp
[cpus=]n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]
Simulate an SMP system with n CPUs. On the PC target, up to 255
CPUs are supported. On Sparc32 target, Linux limits the number of usable
CPUs to 4. For the PC target, the number of cores per
socket, the number of threads per cores and the total number of
sockets can be specified. Missing values will be computed. *If any on the
three values is given, the total number of CPUs n can be
omitted*. maxcpus specifies the maximum number of hotpluggable
CPUs.
So, I built the master branch of libvirt and tested the following:
Client:
$ ./run ./tools/virsh domxml-from-native qemu-argv <(echo
'/usr/bin/qemu-system-x86_64 -enable-kvm -smp cores=2,threads=1,sockets=1')
error: Disconnected from qemu:///session due to I/O error
error: Cannot recv data: Connection reset by peer
Server:
$ ./run gdb ./daemon/libvirtd
GNU gdb (GDB) Fedora 7.11.1-86.fc24
...
Starting program: /home/wani/libvirt/daemon/.libs/lt-libvirtd
[Thread debugging using libthread_db enabled]
...
[Thread 0x7fffc462c700 (LWP 16850) exited]
...
Thread 4 "lt-libvirtd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe4cf1700 (LWP 16836)]
qemuDomainDefVcpusPostParse (def=0x7fffb8000ec0) at qemu/qemu_domain.c:2480
2480 if (!vcpu->online) {
qemuDomainDefVcpusPostParse() calls vcpu = virDomainDefGetVcpu(def, 0),
which returns NULL.
I'd be happy to send a patch, but I am not sure what the right solution is.
- Should not specifying n to -smp allowed?
I don't understand that ^^.
- Should -cpus=n also be parsed in qemuParseCommandLineSmp()?
But the parsing code should be fixed. Looks like the value could be
just computed. But domxml-to-native is not very used I believe.
Cheers!
Nehal J Wani
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
3:46 a.m.
On Mon, Nov 14, 2016 at 09:50:02 +0100, Martin Kletzander wrote:
On Sun, Nov 13, 2016 at 11:15:29PM +0530, Nehal J Wani wrote:
>The man page of qemu(2.6.2), states the following:
>
> -smp
>[cpus=]n[,cores=cores][,threads=threads][,sockets=sockets][,maxcpus=maxcpus]
> Simulate an SMP system with n CPUs. On the PC target, up to 255
>CPUs are supported. On Sparc32 target, Linux limits the number of usable
>CPUs to 4. For the PC target, the number of cores per
> socket, the number of threads per cores and the total number of
>sockets can be specified. Missing values will be computed. *If any on the
>three values is given, the total number of CPUs n can be
> omitted*. maxcpus specifies the maximum number of hotpluggable
>CPUs.
>
>So, I built the master branch of libvirt and tested the following:
>
>Client:
>
>$ ./run ./tools/virsh domxml-from-native qemu-argv <(echo
>'/usr/bin/qemu-system-x86_64 -enable-kvm -smp cores=2,threads=1,sockets=1')
This command line is parsed as having 0 online cpus and 0 maximum cpus
in libvirt as we did not update the code for a while.
>error: Disconnected from qemu:///session due to I/O error
>error: Cannot recv data: Connection reset by peer
>
>Server:
>
>$ ./run gdb ./daemon/libvirtd
>GNU gdb (GDB) Fedora 7.11.1-86.fc24
>...
>Starting program: /home/wani/libvirt/daemon/.libs/lt-libvirtd
>[Thread debugging using libthread_db enabled]
>...
>[Thread 0x7fffc462c700 (LWP 16850) exited]
>...
>Thread 4 "lt-libvirtd" received signal SIGSEGV, Segmentation fault.
>[Switching to Thread 0x7fffe4cf1700 (LWP 16836)]
>qemuDomainDefVcpusPostParse (def=0x7fffb8000ec0) at qemu/qemu_domain.c:2480
>2480 if (!vcpu->online) {
>
>
>qemuDomainDefVcpusPostParse() calls vcpu = virDomainDefGetVcpu(def, 0),
>which returns NULL.
This happens as the code happily sets vcpus to 0. The post parse code
expects at least 1 vcpu.
>
>I'd be happy to send a patch, but I am not sure what the right solution is.
>
>- Should not specifying n to -smp allowed?
I don't understand that ^^.
>- Should -cpus=n also be parsed in qemuParseCommandLineSmp()?
>
But the parsing code should be fixed. Looks like the value could be
just computed. But domxml-to-native is not very used I believe.
There are three issues with the code:
1: if the total calculated vcpu count is 0 libvirt does not reject it
- this causes the crash
2: qemu now supports the cpus= parameter which libvirt does not parse
3: qemu accepts topology as a valid way how to specify maximum cpu count
I'll post patches in a while.
2962
days inactive
2963
days old
2 comments
3 participants
participants (3)
-
Martin Kletzander -
Nehal J Wani -
Peter Krempa