[PATCH] meson: src: Fix DESTDIR handling while creating dirs
by Jan Kiszka
From: Jan Kiszka <jan.kiszka(a)siemens.com>
If the target path contains a link with an absolute path (e.g.
/var/run -> /run), makedirs will target the wrong location. Resolve the
path first, then append DESTDIR again if needed.
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
---
scripts/meson-install-dirs.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/meson-install-dirs.py b/scripts/meson-install-dirs.py
index 14ec6b93e8..e762e44712 100644
--- a/scripts/meson-install-dirs.py
+++ b/scripts/meson-install-dirs.py
@@ -6,4 +6,7 @@ import sys
destdir = os.environ.get('DESTDIR', os.sep)
for dirname in sys.argv[1:]:
- os.makedirs(os.path.join(destdir, dirname.strip(os.sep)), exist_ok=True)
+ realdir = os.path.realpath(os.path.join(destdir, dirname.strip(os.sep)))
+ if not realdir.startswith(destdir):
+ realdir = os.path.join(destdir, realdir.strip(os.sep))
+ os.makedirs(realdir, exist_ok=True)
--
2.26.2
4 years, 2 months
[PATCH] disk storage: fix allocation size for pool format dos
by Sebastian Mitterle
The changed condition was always false because the function was always
called with boundary values 0.
Use the free extent's start value to get its start offset from the
cylinder boundary and determine if the needed size for allocation
needs to be expanded too in case the offset doesn't fit within extra
bytes for alignment.
This fixes an issue where vol-create-from will call qemu-img convert
to create a destination volume of same capacity as the source volume
and qemu-img will error 'Cannot grow device files' due to the partition
being too small for the source although both destination partition and
source volume have the same capacity.
Signed-off-by: Sebastian Mitterle <smitterl(a)redhat.com>
---
src/storage/storage_backend_disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c
index a6d4e41220..ec0679d353 100644
--- a/src/storage/storage_backend_disk.c
+++ b/src/storage/storage_backend_disk.c
@@ -691,7 +691,7 @@ virStorageBackendDiskPartBoundaries(virStoragePoolObjPtr pool,
if (def->source.format == VIR_STORAGE_POOL_DISK_DOS) {
/* align to cylinder boundary */
neededSize += extraBytes;
- if ((*start % cylinderSize) > extraBytes) {
+ if ((dev->freeExtents[i].start % cylinderSize) > extraBytes) {
/* add an extra cylinder if the offset can't fit within
the extra bytes we have */
neededSize += cylinderSize;
--
2.25.2
4 years, 2 months
[PATCH] doc: add some examples for IPv6 NAT configuration
by Ian Wienand
Add some expanded examples for the nat ipv6 introduced with
927acaedec7effbe67a154d8bfa0e67f7d08e6c7.
Unfortunately while for IPv4 it's well-known what addresses ranges are
useful for NAT, with IPv6 unless you enjoy digging through RFC's going
back-and-forth over unique local addresses and the meaning of the word
"site" it's generally much less obvious. I've tried to add some
details on choosing a range inline with RFC 4193 and then some
pointers for when it maybe doesn't work in the guest as you first
expect despite you doing what the RFC's say!
Signed-off-by: Ian Wienand <iwienand(a)redhat.com>
---
docs/formatnetwork.html.in | 47 ++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index fb740111b1..94a4cab4d1 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -1209,6 +1209,53 @@
</ip>
</network></pre>
+ <h3><a id="examplesNATv6">IPv6 NAT based network</a></h3>
+
+ <p>
+ Below is a variation for also providing IPv6 NAT. This can be
+ especially useful when using multiple interfaces where some,
+ such as WiFi cards, can not be bridged (usually on a laptop),
+ making it difficult to provide end-to-end IPv6 routing.
+ </p>
+
+ <pre>
+<network>
+ <name>default6</name>
+ <bridge name="virbr0"/>
+ <forward mode="nat">
+ <nat ipv6='yes'>
+ <port start='1024' end='65535'/>
+ </nat>
+
+ <ip address="192.168.122.1" netmask="255.255.255.0">
+ <dhcp>
+ <range start="192.168.122.2" end="192.168.122.254"/>
+ </dhcp>
+ </ip>
+ <ip family="ipv6" address="fdXX:XXXX:XXXX:NNNN:: prefix="64"/>
+ </ip>
+</network></pre>
+
+ <p>IPv6 NAT addressing has some caveats over the more straight
+ forward IPv4 case.
+ <a href="https://tools.ietf.org/html/rfc4193">RFC 4193</a>
+ defines the address range <tt>fd00::/8</tt> for <tt>/48</tt> IPv6
+ private networks. It should be concatenated with a random 40-bit
+ string (i.e. 10 random hexadecimal digits replacing the <tt>X</tt>
+ values above, RFC 4193 provides
+ an <a href="https://tools.ietf.org/html/rfc4193#section-3.2.2">algorithm</a>
+ if you do not have a source of sufficient randomness). This
+ leaves <tt>0</tt> through <tt>ffff</tt> for subnets (<tt>N</tt>
+ above) which you can use at will.</p>
+
+ <p>Many operating systems will not consider these addresses as
+ preferential to IPv4, due to some practial history of these
+ addresses being present but unroutable and causing networking
+ issues. On many Linux distributions, you may need to
+ override <tt>/etc/gai.conf</tt> with values
+ from <a href="https://www.ietf.org/rfc/rfc3484.txt">RFC 3484</a>
+ to have your IPv6 NAT network correctly preferenced over IPv4.</p>
+
<h3><a id="examplesRoute">Routed network config</a></h3>
<p>
--
2.26.2
4 years, 2 months
[PATCH] client: fix memory leak in client msg
by Hao Wang
>From 3ad3fae4f2562a11bef8dcdd25b6a7e0b00d4e2c Mon Sep 17 00:00:00 2001
From: Hao Wang <wanghao232(a)huawei.com>
Date: Sat, 18 Jul 2020 15:43:30 +0800
Subject: [PATCH] client: fix memory leak in client msg
When closing client->waitDispatch in virNetClientIOEventLoopRemoveAll
or virNetClientIOEventLoopRemoveDone, VIR_FREE() is called to free
call->msg directly, resulting in leak of the memory call->msg->buffer
points to.
Use virNetMessageFree(call->msg) instead of VIR_FREE(call->msg).
Signed-off-by: Hao Wang <wanghao232(a)huawei.com>
---
src/rpc/virnetclient.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c
index 441f1502a6..f899493b64 100644
--- a/src/rpc/virnetclient.c
+++ b/src/rpc/virnetclient.c
@@ -1519,7 +1519,7 @@ static bool virNetClientIOEventLoopRemoveDone(virNetClientCallPtr call,
if (call->expectReply)
VIR_WARN("Got a call expecting a reply but without a waiting thread");
virCondDestroy(&call->cond);
- VIR_FREE(call->msg);
+ virNetMessageFree(call->msg);
VIR_FREE(call);
}
@@ -1546,7 +1546,7 @@ virNetClientIOEventLoopRemoveAll(virNetClientCallPtr call,
VIR_DEBUG("Removing call %p", call);
virCondDestroy(&call->cond);
- VIR_FREE(call->msg);
+ virNetMessageFree(call->msg);
VIR_FREE(call);
return true;
}
--
2.23.0
4 years, 2 months
[PATCH v2 05/10] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
by Alex Bennée
It's buggy and we are not sure anyone uses it.
Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org>
Reviewed-by: Richard Henderson <richard.henderson(a)linaro.org>
Acked-by: David Gibson <david(a)gibson.dropbear.id.au>
---
docs/system/deprecated.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 851dbdeb8ab..a158e765c33 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -424,6 +424,13 @@ linux-user mode) is deprecated and will be removed in a future version
of QEMU. Support for this CPU was removed from the upstream Linux
kernel in 2018, and has also been dropped from glibc.
+``ppc64abi32`` CPUs (since 5.2.0)
+'''''''''''''''''''''''''''''''''
+
+The ``ppc64abi32`` architecture has a number of issues which regularly
+trip up our CI testing and is suspected to be quite broken. For that
+reason the maintainers strongly suspect no one actually uses it.
+
Related binaries
----------------
--
2.20.1
4 years, 2 months
[libvirt PATCH] virsh: cmdScreenshot: fix cbdata passing to virshStreamSink
by Ján Tomko
The changes for sparse stream support started passing
virshStreamCallbackDataPtr to virshStreamSink
instead of passing a simple file descriptor, but
forgot to adjust all the callers.
Fix it in cmdScreenshot as well.
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
Fixes: 9e745a97171e10f050962c166082439d6724e245
https://bugzilla.redhat.com/show_bug.cgi?id=1875195
---
tools/virsh-domain.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 31597ee469..d1d3f8e566 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -5628,6 +5628,7 @@ cmdScreenshot(vshControl *ctl, const vshCmd *cmd)
bool generated = false;
char *mime = NULL;
virshControlPtr priv = ctl->privData;
+ virshStreamCallbackData cbdata;
if (vshCommandOptStringReq(ctl, cmd, "file", (const char **) &file) < 0)
return false;
@@ -5663,7 +5664,10 @@ cmdScreenshot(vshControl *ctl, const vshCmd *cmd)
created = true;
}
- if (virStreamRecvAll(st, virshStreamSink, &fd) < 0) {
+ cbdata.ctl = ctl;
+ cbdata.fd = fd;
+
+ if (virStreamRecvAll(st, virshStreamSink, &cbdata) < 0) {
vshError(ctl, _("could not receive data from domain %s"), name);
goto cleanup;
}
--
2.26.2
4 years, 2 months
remove cache for hooks
by Kirill Ponomarev
Hi all,
at the moment if there's no hook defined and installed, libvirtd caches
this fact at start and don't add it even if hookds are added/stopped
later. So libvirtd restart is required to hook up the hook.
What do you think if we disable caching for that reason to allow
adding/removing hooks while libvirtd is running?
Any thoughts and/or objections?
4 years, 2 months
[PATCH] qemuFirmwareFillDomain: Fill NVRAM template on migration too
by Michal Privoznik
In 8e1804f9f66 I've tried to fix the following use case: domain
is started with path to UEFI only and relies on libvirt to figure
out corresponding NVRAM template to create a per-domain copy
from. The fix consisted of having a check tailored exactly for
this use case and if it's hit then using FW autoselection to
figure it out. Unfortunately, the NVRAM template is not saved in
the inactive XML (well, the domain might be transient anyway).
Then, as a part of that check we see whether the per-domain copy
doesn't exist already and if it does then no template is looked
up hence no template will appear in the live XML.
This works, until the domain is migrated. At the destination, the
per-domain copy will not exist so we need to know the template to
create the per-domain copy from. But we don't even get to the
check because we are not starting a fresh new domain and thus the
qemuFirmwareFillDomain() function quits early.
The solution is to switch order of these two checks. That is
evaluate the check for the old style before checking flags.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1852910
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_firmware.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
index 2edc0efabb..ffe2df20aa 100644
--- a/src/qemu/qemu_firmware.c
+++ b/src/qemu/qemu_firmware.c
@@ -1228,9 +1228,6 @@ qemuFirmwareFillDomain(virQEMUDriverPtr driver,
size_t i;
int ret = -1;
- if (!(flags & VIR_QEMU_PROCESS_START_NEW))
- return 0;
-
/* Fill in FW paths if either os.firmware is enabled, or
* loader path was provided with no nvram varstore. */
if (def->os.firmware == VIR_DOMAIN_OS_DEF_FIRMWARE_NONE) {
@@ -1246,6 +1243,11 @@ qemuFirmwareFillDomain(virQEMUDriverPtr driver,
/* ... then we want to consult JSON FW descriptors first,
* but we don't want to fail if we haven't found a match. */
needResult = false;
+ } else {
+ /* Domain has FW autoselection enabled => do nothing if
+ * we are not starting it from scratch. */
+ if (!(flags & VIR_QEMU_PROCESS_START_NEW))
+ return 0;
}
if ((nfirmwares = qemuFirmwareFetchParsedConfigs(driver->privileged,
--
2.26.2
4 years, 2 months
[libvirt PATCH v2 0/2] Use g_auto* in src/cpu/*.
by Tim Wiederhake
V1: https://www.redhat.com/archives/libvir-list/2020-September/msg00355.html
Changes since V1:
* Most patches already commited, this is the remainder.
* Incorporated comment from Ján into patch #1.
* Rebased on top of Daniels patches.
With these patches, src/cpu/ becomes `goto` free.
Tim Wiederhake (2):
cpu_map: Use g_auto* in loadData
cpu_ppc64: Remove error path in virCPUppc64DriverGetModels
src/cpu/cpu_map.c | 18 ++++++------------
src/cpu/cpu_ppc64.c | 11 ++---------
2 files changed, 8 insertions(+), 21 deletions(-)
--
2.26.2
4 years, 2 months
[PATCH] docs: Discourage users from using fwcfg
by Michal Privoznik
Even though this was brought up in upstream discussion [1] it
missed my patches: users should prefer <oemStrings/> over fwcfg.
The reason is that fwcfg is considered somewhat internal to QEMU
and it has limited number of slots and neither of these applies
to <oemStrings/>.
While I'm at it, I'm fixing the example too (because it contains
incorrect element name) and clarifying sysfs/ exposure.
1: https://www.redhat.com/archives/libvir-list/2020-May/msg00957.html
Reported-by: Laszlo Ersek <lersek(a)redhat.com>
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 1979dfb8d3..821ffe8d60 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -509,18 +509,22 @@ layout of sub-elements, with supported values of:
Some hypervisors provide unified way to tweak how firmware configures itself,
or may contain tables to be installed for the guest OS, for instance boot
order, ACPI, SMBIOS, etc. It even allows users to define their own config
- blobs. In case of QEMU, these then appear under domain's sysfs, under
+ blobs. In case of QEMU, these then appear under domain's sysfs (if the guest
+ kernel has FW_CFG_SYSFS config option enabled), under
``/sys/firmware/qemu_fw_cfg``. Note, that these values apply regardless the
<smbios/> mode under <os/>. :since:`Since 6.5.0`
+ **Please note that because of limited number of data slots use of fwcfg is
+ strongly discouraged and <oemStrings/> should be used instead**.
+
::
- <smbios type='fwcfg'>
+ <sysinfo type='fwcfg'>
<entry name='opt/com.example/name'>example value</entry>
- <entry name='opt/com.coreos/config' file='/tmp/provision.ign'/>
- </smbios>
+ <entry name='opt/com.example/config' file='/tmp/provision.ign'/>
+ </sysinfo>
- The ``smbios`` element can have multiple ``entry`` child elements. Each
+ The ``sysinfo`` element can have multiple ``entry`` child elements. Each
element then has mandatory ``name`` attribute, which defines the name of the
blob and must begin with ``"opt/"`` and to avoid clashing with other names is
advised to be in form ``"opt/$RFQDN/$name"`` where ``$RFQDN`` is a reverse
--
2.26.2
4 years, 2 months
