[libvirt] [PATCH] qemu: Introduce 16550A serial console model
by Andrea Bolognani
None of the existing models is suitable for use with
RISC-V virt guests, and we don't want information about
the serial console to be missing from the XML.
The name is based on comments in qemu/hw/riscv/virt.c:
RISC-V machine with 16550a UART and VirtIO MMIO
and in qemu/hw/char/serial.c:
QEMU 16550A UART emulation
along with the output of dmesg in the guest:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
base_baud= 230400) is a 16550A
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
CC'ing Rich mostly so that he can double-check the name
choice is sensible.
docs/formatdomain.html.in | 12 +++++-----
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_command.c | 12 ++++++++++
src/qemu/qemu_domain.c | 27 ++++++++++++++++-------
tests/qemuxml2xmloutdata/riscv64-virt.xml | 4 +++-
7 files changed, 44 insertions(+), 14 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0cbf570a13..eb619a1656 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -7011,7 +7011,8 @@ qemu-kvm -net nic,model=? /dev/null
is available) and <code>pci-serial</code> (usable whenever PCI support
is available); <span class="since">since 3.10.0</span>,
<code>spapr-vio-serial</code> (usable with ppc64/pseries guests),
- <code>system-serial</code> (usable with aarch64/virt guests) and
+ <code>system-serial</code> (usable with aarch64/virt and,
+ <span class="since">since 4.7.0</span>, riscv/virt guests) and
<code>sclp-serial</code> (usable with s390 and s390x guests) are
available as well.
</p>
@@ -7025,10 +7026,11 @@ qemu-kvm -net nic,model=? /dev/null
target type); <code>pci-serial</code>
(usable with the <code>pci-serial</code> target type);
<code>spapr-vty</code> (usable with the <code>spapr-vio-serial</code>
- target type); <code>pl011</code> (usable with the
- <code>system-serial</code> target type); <code>sclpconsole</code> and
- <code>sclplmconsole</code> (usable with the <code>sclp-serial</code>
- target type).
+ target type); <code>pl011</code> and,
+ <span class="since">since 4.7.0</span>, <code>16550a</code> (usable
+ with the <code>system-serial</code> target type);
+ <code>sclpconsole</code> and <code>sclplmconsole</code> (usable with
+ the <code>sclp-serial</code> target type).
</p>
<p>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index f176538195..3796eb4b5e 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3733,6 +3733,7 @@
<value>pci-serial</value>
<value>spapr-vty</value>
<value>pl011</value>
+ <value>16550a</value>
<value>sclpconsole</value>
<value>sclplmconsole</value>
</choice>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index bde9fef914..8af59bb4bb 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -493,6 +493,7 @@ VIR_ENUM_IMPL(virDomainChrSerialTargetModel,
"pl011",
"sclpconsole",
"sclplmconsole",
+ "16550a",
);
VIR_ENUM_IMPL(virDomainChrDevice, VIR_DOMAIN_CHR_DEVICE_TYPE_LAST,
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c0ad072db5..8a3673361a 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1133,6 +1133,7 @@ typedef enum {
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011,
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPCONSOLE,
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPLMCONSOLE,
+ VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A,
VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_LAST
} virDomainChrSerialTargetModel;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index fd9e58fd5d..f63e35444e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -9149,6 +9149,7 @@ qemuChrSerialTargetModelToCaps(virDomainChrSerialTargetModel targetModel)
return QEMU_CAPS_DEVICE_SCLPLMCONSOLE;
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011:
return QEMU_CAPS_DEVICE_PL011;
+ case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_NONE:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_LAST:
break;
@@ -9189,6 +9190,16 @@ qemuChrIsPlatformDevice(const virDomainDef *def,
}
}
+ if (ARCH_IS_RISCV(def->os.arch)) {
+
+ /* 16550a (used by riscv/virt guests) is a platform device */
+ if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL &&
+ chr->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM &&
+ chr->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A) {
+ return true;
+ }
+ }
+
/* If we got all the way here and we're still stuck with the default
* target type for a serial device, it means we have no clue what kind of
* device we're talking about and we must treat it as a platform device. */
@@ -10579,6 +10590,7 @@ qemuBuildSerialChrDeviceStr(char **deviceStr,
break;
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011:
+ case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_NONE:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_LAST:
/* Except from _LAST, which is just a guard value and will never
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 886e3fbb72..1cc4cefbd1 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -4183,6 +4183,7 @@ qemuDomainChrSerialTargetModelToTargetType(int targetModel)
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SPAPR_VTY:
return VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR_VIO;
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011:
+ case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A:
return VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM;
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPCONSOLE:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPLMCONSOLE:
@@ -4248,6 +4249,7 @@ qemuDomainChrTargetDefValidate(const virDomainChrDef *chr)
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPCONSOLE:
case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPLMCONSOLE:
+ case VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A:
expected = qemuDomainChrSerialTargetModelToTargetType(chr->targetModel);
@@ -4298,18 +4300,23 @@ qemuDomainChrDefValidate(const virDomainChrDef *dev,
if (dev->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL) {
bool isCompatible = true;
+ if (dev->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM) {
+ if (dev->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011 &&
+ !qemuDomainIsARMVirt(def)) {
+ isCompatible = false;
+ }
+ if (dev->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A &&
+ !qemuDomainIsRISCVVirt(def)) {
+ isCompatible = false;
+ }
+ }
+
if (!qemuDomainIsPSeries(def) &&
(dev->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR_VIO ||
dev->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SPAPR_VTY)) {
isCompatible = false;
}
- if (!qemuDomainIsARMVirt(def) &&
- (dev->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM ||
- dev->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011)) {
- isCompatible = false;
- }
-
if (!ARCH_IS_S390(def->os.arch) &&
(dev->targetType == VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP ||
dev->targetModel == VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPCONSOLE ||
@@ -6129,7 +6136,7 @@ qemuDomainChrDefPostParse(virDomainChrDefPtr chr,
chr->targetType = VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_ISA;
} else if (qemuDomainIsPSeries(def)) {
chr->targetType = VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SPAPR_VIO;
- } else if (qemuDomainIsARMVirt(def)) {
+ } else if (qemuDomainIsARMVirt(def) || qemuDomainIsRISCVVirt(def)) {
chr->targetType = VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM;
} else if (ARCH_IS_S390(def->os.arch)) {
chr->targetType = VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP;
@@ -6153,7 +6160,11 @@ qemuDomainChrDefPostParse(virDomainChrDefPtr chr,
chr->targetModel = VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SPAPR_VTY;
break;
case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SYSTEM:
- chr->targetModel = VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011;
+ if (qemuDomainIsARMVirt(def)) {
+ chr->targetModel = VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_PL011;
+ } else if (qemuDomainIsRISCVVirt(def)) {
+ chr->targetModel = VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_16550A;
+ }
break;
case VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP:
chr->targetModel = VIR_DOMAIN_CHR_SERIAL_TARGET_MODEL_SCLPCONSOLE;
diff --git a/tests/qemuxml2xmloutdata/riscv64-virt.xml b/tests/qemuxml2xmloutdata/riscv64-virt.xml
index 822a59a604..daf9ca4978 100644
--- a/tests/qemuxml2xmloutdata/riscv64-virt.xml
+++ b/tests/qemuxml2xmloutdata/riscv64-virt.xml
@@ -24,7 +24,9 @@
</disk>
<controller type='usb' index='0'/>
<serial type='pty'>
- <target port='0'/>
+ <target type='system-serial' port='0'>
+ <model name='16550a'/>
+ </target>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
--
2.17.1
6 years, 7 months
[libvirt] [PATCH] qemu: Add more defaults for RISC-V virt guests
by Andrea Bolognani
We would have used virtio for networking anyway, but it's
better to be explicit; for graphics, none of the existing
models work right now but virtio is the only one which
has a non-PCI variant, so it's as good a default as any.
Spotted-by: Ján Tomko <jtomko(a)redhat.com>
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
src/qemu/qemu_domain.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 22c6d8f090..2410add9c2 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5840,6 +5840,10 @@ qemuDomainDefaultNetModel(const virDomainDef *def,
return "lan9118";
}
+ /* virtio is a sensible default for RISC-V virt guests */
+ if (qemuDomainIsRISCVVirt(def))
+ return "virtio";
+
/* In all other cases the model depends on the capabilities. If they were
* not provided don't report any default. */
if (!qemuCaps)
@@ -6326,7 +6330,9 @@ qemuDomainDeviceVideoDefPostParse(virDomainVideoDefPtr video,
if (video->type == VIR_DOMAIN_VIDEO_TYPE_DEFAULT) {
if (ARCH_IS_PPC64(def->os.arch))
video->type = VIR_DOMAIN_VIDEO_TYPE_VGA;
- else if (qemuDomainIsARMVirt(def) || ARCH_IS_S390(def->os.arch))
+ else if (qemuDomainIsARMVirt(def) ||
+ qemuDomainIsRISCVVirt(def) ||
+ ARCH_IS_S390(def->os.arch))
video->type = VIR_DOMAIN_VIDEO_TYPE_VIRTIO;
else
video->type = VIR_DOMAIN_VIDEO_TYPE_CIRRUS;
--
2.17.1
6 years, 7 months
[libvirt] [PATCH] qemu: Don't use legacy USB for RISC-V guests
by Andrea Bolognani
The architecture is new enough that we don't need to
concern ourselves with backwards compatibility in any
capacity.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Requires
https://www.redhat.com/archives/libvir-list/2018-June/msg01223.html
to be applied (and test data to be refreshed in the process).
src/qemu/qemu_command.c | 4 +++-
tests/qemuxml2argvdata/riscv64-virt.args | 1 -
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 88d698e262..bac7c938ab 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3046,7 +3046,8 @@ qemuBuildControllerDevCommandLine(virCommandPtr cmd,
if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_DEFAULT &&
!qemuDomainIsQ35(def) &&
- !qemuDomainIsARMVirt(def)) {
+ !qemuDomainIsARMVirt(def) &&
+ !qemuDomainIsRISCVVirt(def)) {
/* An appropriate default USB controller model should already
* have been selected in qemuDomainDeviceDefPostParse(); if
@@ -3085,6 +3086,7 @@ qemuBuildControllerDevCommandLine(virCommandPtr cmd,
if (usbcontroller == 0 &&
!qemuDomainIsQ35(def) &&
!qemuDomainIsARMVirt(def) &&
+ !qemuDomainIsRISCVVirt(def) &&
!ARCH_IS_S390(def->os.arch)) {
/* We haven't added any USB controller yet, but we haven't been asked
* not to add one either. Add a legacy USB controller, unless we're
diff --git a/tests/qemuxml2argvdata/riscv64-virt.args b/tests/qemuxml2argvdata/riscv64-virt.args
index 0e103a6755..a373ff2b92 100644
--- a/tests/qemuxml2argvdata/riscv64-virt.args
+++ b/tests/qemuxml2argvdata/riscv64-virt.args
@@ -21,7 +21,6 @@ server,nowait \
-no-shutdown \
-kernel /var/lib/libvirt/images/bbl \
-append 'console=ttyS0 ro root=/dev/vda' \
--usb \
-drive file=/var/lib/libvirt/images/stage4-disk.img,format=raw,if=none,\
id=drive-virtio-disk0 \
-device virtio-blk-device,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
--
2.17.1
6 years, 7 months
[libvirt] [PATCH v2] docs: api_extension: Update paths in the examples
by Peter Krempa
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
v2:
- switched from '$SECTION' to '$MODULE' as a hint for the split files
- changed 'domain.rng' to 'domaincommon.rng' which contains the defs
- added the '$MODULE' to virsh path
Note some still may be wrong as I did not chec all paths rigorously.
docs/api_extension.html.in | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/docs/api_extension.html.in b/docs/api_extension.html.in
index 33d82e6ac6..d7fbbd6e90 100644
--- a/docs/api_extension.html.in
+++ b/docs/api_extension.html.in
@@ -96,7 +96,7 @@
schema and document the new elements or attributes:</p>
<p><code>
- docs/schemas/domain.rng<br/>
+ docs/schemas/domaincommon.rng<br/>
docs/formatdomain.html.in
</code></p>
@@ -106,7 +106,7 @@
libvirt library and call the new function:</p>
<p><code>
- include/libvirt/libvirt.h.in
+ include/libvirt/libvirt-$MODULE.h.in
src/libvirt_public.syms
</code></p>
@@ -137,7 +137,7 @@
<p>The driver structs are defined in:</p>
- <p><code>src/driver.h</code></p>
+ <p><code>src/driver-$MODULE.h</code></p>
<p>
To define the internal API, first typedef the driver function
@@ -177,7 +177,7 @@
<p>The public API calls are implemented in:</p>
- <p><code>src/libvirt.c</code></p>
+ <p><code>src/libvirt-$MODULE.c</code></p>
<h2><a name='remoteproto'>Implementing the remote protocol</a></h2>
@@ -219,9 +219,9 @@
</p>
<p><code>
- daemon/remote_dispatch_args.h
- daemon/remote_dispatch_prototypes.h
- daemon/remote_dispatch_table.h
+ src/remote/remote_daemon_dispatch_stubs.h
+ src/remote/remote_daemon_dispatch.h
+ src/remote/remote_daemon_dispatch.c
src/remote/remote_protocol.c
src/remote/remote_protocol.h
</code></p>
@@ -233,7 +233,7 @@
method calls go in:
</p>
- <p><code>src/remote/remote_internal.c</code></p>
+ <p><code>src/remote/remote_driver.c</code></p>
<p>Each remote method invocation does the following:</p>
@@ -256,7 +256,7 @@
The server side dispatchers are implemented in:
</p>
- <p><code>daemon/remote.c</code></p>
+ <p><code>src/remote/daemon_dispatch.c</code></p>
<p>Again, this step uses the .h files generated by make rpcgen.</p>
@@ -309,7 +309,7 @@
</p>
<p><code>
- tools/virsh.c<br/>
+ tools/virsh-$MODULE.c<br/>
tools/virsh.pod
</code></p>
--
2.16.2
6 years, 7 months
[libvirt] [PATCH v5 0/3] vsh: Introduce new API for printing tables
by Simon Kobyda
Created new API for priting tables, mainly to solve alignment problems.
Implemented these test to virsh list. In the future, API may be
everywhere in virsh and virt-admin.
Also wrote basic tests for the new API, and corrected tests in virshtest
which are influenced by implementation of the API in virsh list.
Changes in v5:
- cleanup and merged code for calculating zero-width, nonprintable and combined
character.
- replaced virBufferAddStr with virBufferAddChar in some places
- in tests moved code for setting correct locale
- fixed few leaks and unitialized values
Changes in v4:
- fixed width calculation for zero-width, nonprintable and combined
character. (pulled some code from linux-util)
- added tests for cases mentioned above
- changed usage of vshControl variables. From now on PrintToStdout calls
PrintToString and then prints returned string to stdout
Changes in v3:
- changed encoding of 3/3 patch, otherwise it cannot be applied
Changes in v2:
- added tests
- fixed alignment for unicode character which span more spaces
- moved ncolumns check to vshTableRowAppend
- changed arguments for functions vshTablePrint, vshTablePrintToStdout,
vshTablePrintToString
Simon Kobyda (3):
vsh: Add API for printing tables.
virsh: Implement new table API for virsh list
vsh: Added tests
tests/Makefile.am | 8 +
tests/virshtest.c | 14 +-
tests/vshtabletest.c | 377 +++++++++++++++++++++++++++++
tools/Makefile.am | 4 +-
tools/virsh-domain-monitor.c | 43 ++--
tools/vsh-table.c | 449 +++++++++++++++++++++++++++++++++++
tools/vsh-table.h | 42 ++++
7 files changed, 910 insertions(+), 27 deletions(-)
create mode 100644 tests/vshtabletest.c
create mode 100644 tools/vsh-table.c
create mode 100644 tools/vsh-table.h
--
2.17.1
6 years, 7 months
[libvirt] [PATCH v4] vl.c deprecate incorrect CPUs topology
by Igor Mammedov
-smp [cpus],sockets/cores/threads[,maxcpus] should describe topology
so that total number of logical CPUs [sockets * cores * threads]
would be equal to [maxcpus], however historically we didn't have
such check in QEMU and it is possible to start VM with an invalid
topology.
Deprecate invalid options combination so we can make sure that
the topology VM started with is always correct in the future.
Users with an invalid sockets/cores/threads/maxcpus values should
fix their CLI to make sure that
[sockets * cores * threads] == [maxcpus]
Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>
---
v4:
- missed dot comment, fix it with s/./,/ (Andrew Jones <drjones(a)redhat.com>)
v3:
- more spelling fixes (Andrew Jones <drjones(a)redhat.com>)
- place deprecation check after (sockets * cores * threads > max_cpus) check
(Eduardo Habkost <ehabkost(a)redhat.com>)
v2:
- spelling&&co fixes (Andrew Jones <drjones(a)redhat.com>)
---
qemu-deprecated.texi | 11 +++++++++++
vl.c | 7 +++++++
2 files changed, 18 insertions(+)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 87212b6..094b4ca 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -159,6 +159,17 @@ The 'file' driver for drives is no longer appropriate for character or host
devices and will only accept regular files (S_IFREG). The correct driver
for these file types is 'host_cdrom' or 'host_device' as appropriate.
+@subsection -smp X,[socket=a,core=b,thread=c],maxcpus=Y (since 3.1)
+
+CPU topology properties should describe whole machine topology including
+possible CPUs, but historically it was possible to start QEMU with
+an incorrect topology where
+ sockets * cores * threads >= X && X < maxcpus
+which could lead to an incorrect topology enumeration by the guest.
+Support for invalid topologies will be removed, the user must ensure
+topologies described with -smp include all possible cpus, i.e.
+ sockets * cores * threads == maxcpus
+
@section QEMU Machine Protocol (QMP) commands
@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
diff --git a/vl.c b/vl.c
index 5ba06ad..7fd700e 100644
--- a/vl.c
+++ b/vl.c
@@ -1246,6 +1246,13 @@ static void smp_parse(QemuOpts *opts)
exit(1);
}
+ if (sockets * cores * threads != max_cpus) {
+ warn_report("Invalid CPU topology deprecated: "
+ "sockets (%u) * cores (%u) * threads (%u) "
+ "!= maxcpus (%u)",
+ sockets, cores, threads, max_cpus);
+ }
+
smp_cpus = cpus;
smp_cores = cores;
smp_threads = threads;
--
2.7.4
6 years, 7 months
[libvirt] [PATCH v3] vl.c deprecate incorrect CPUs topology
by Igor Mammedov
-smp [cpus],sockets/cores/threads[,maxcpus] should describe topology
so that total number of logical CPUs [sockets * cores * threads]
would be equal to [maxcpus], however historically we didn't have
such check in QEMU and it is possible to start VM with an invalid
topology.
Deprecate invalid options combination so we can make sure that
the topology VM started with is always correct in the future.
Users with an invalid sockets/cores/threads/maxcpus values should
fix their CLI to make sure that
[sockets * cores * threads] == [maxcpus]
Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>
---
v3:
- more spelling fixes (Andrew Jones <drjones(a)redhat.com>)
- place deprecation check after (sockets * cores * threads > max_cpus) check
(Eduardo Habkost <ehabkost(a)redhat.com>)
v2:
- spelling&&co fixes (Andrew Jones <drjones(a)redhat.com>)
---
qemu-deprecated.texi | 11 +++++++++++
vl.c | 7 +++++++
2 files changed, 18 insertions(+)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 87212b6..dc9d9ee 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -159,6 +159,17 @@ The 'file' driver for drives is no longer appropriate for character or host
devices and will only accept regular files (S_IFREG). The correct driver
for these file types is 'host_cdrom' or 'host_device' as appropriate.
+@subsection -smp X,[socket=a,core=b,thread=c],maxcpus=Y (since 3.1)
+
+CPU topology properties should describe whole machine topology including
+possible CPUs. but historically it was possible to start QEMU with
+an incorrect topology where
+ sockets * cores * threads >= X && X < maxcpus
+which could lead to an incorrect topology enumeration by the guest.
+Support for invalid topologies will be removed, the user must ensure
+topologies described with -smp include all possible cpus, i.e.
+ sockets * cores * threads == maxcpus
+
@section QEMU Machine Protocol (QMP) commands
@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
diff --git a/vl.c b/vl.c
index 5ba06ad..7fd700e 100644
--- a/vl.c
+++ b/vl.c
@@ -1246,6 +1246,13 @@ static void smp_parse(QemuOpts *opts)
exit(1);
}
+ if (sockets * cores * threads != max_cpus) {
+ warn_report("Invalid CPU topology deprecated: "
+ "sockets (%u) * cores (%u) * threads (%u) "
+ "!= maxcpus (%u)",
+ sockets, cores, threads, max_cpus);
+ }
+
smp_cpus = cpus;
smp_cores = cores;
smp_threads = threads;
--
2.7.4
6 years, 7 months
[libvirt] [PATCH] qemuargv2xmltest: Fix caps loading in VPATH build
by Jiri Denemark
Broken by v4.7.0-rc1-9-g6700062fb0.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
Pushed as build-breaker fix.
---
tests/qemuargv2xmltest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemuargv2xmltest.c b/tests/qemuargv2xmltest.c
index 966e75ef5f..7e250b7b9d 100644
--- a/tests/qemuargv2xmltest.c
+++ b/tests/qemuargv2xmltest.c
@@ -159,7 +159,7 @@ mymain(void)
do { \
virQEMUCapsPtr qemuCaps; \
qemuCaps = qemuTestParseCapabilitiesArch(VIR_ARCH_X86_64, \
- "qemucapabilitiesdata/caps_2.12.0." arch ".xml"); \
+ abs_srcdir "/qemucapabilitiesdata/caps_2.12.0." arch ".xml"); \
if (virFileCacheInsertData(driver.qemuCapsCache, \
"/usr/bin/qemu-system-" arch, \
qemuCaps) < 0) \
--
2.18.0
6 years, 7 months
[libvirt] question about job handling across migration protocol phases
by Jim Fehlig
While investigating a bug [1] found by Xen's osstest I realized I don't quite
understand how to handle modify jobs (e.g. BeginJob/EndJob) on virDomainObj
across the various phases of V3 migration protocol. E.g. on the src host the
Begin, Perform, and Confirm phases are performed. Should a modify job start
(BeginJob) in the Begin phase and stop (EndJob) in the Confirm phase? Or should
each phase, if necessary, do BeginJob/EndJob? Same question for dst host. IMO
the job should be held across the phases on each host, preventing any
modifications during the overall migration process. Although I do worry about
orphaned jobs, e.g. a missed EndJob caused by some obscure error in the
migration machinery.
Regards,
Jim
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01945.html
6 years, 7 months
