address, but
this function was still creating a temporary virPCIDeviceAddress, then
copying the individual elements into this temporary object from the
same type of object in the virDomainHostDevDef.
This patch just eliminates that pointless copy.
Signed-off-by: Laine Stump
---
src/hypervisor
There is no need for a temporary variable in this function, and ever
since we switched to glib for memory allocation, there is no possibility
it can return NULL, so callers don't need to check for it.
Signed-off-by: Laine Stump
---
src/util/virpci.c | 34 ++
1
These were nops once enough cleanup was g_auto'd.
Signed-off-by: Laine Stump
---
src/util/virpci.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index c7ee259e29..855872031e 100644
--- a/src/util
virPCIDeviceAddressGetSysfsFile() is simpler to call.
Signed-off-by: Laine Stump
---
src/util/virnetdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index 088f35621d..e284d62233 100644
--- a/src/util/virnetdev.c
+++ b/src
Signed-off-by: Laine Stump
---
src/libvirt_private.syms | 1 -
src/util/virpci.c| 15 ---
src/util/virpci.h| 4
3 files changed, 20 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index ae543589f1..b2d786409b 100644
--- a/src
On 10/15/20 7:21 AM, zhenwei pi wrote:
Suggested by Laine:
virNetDevParseVfConfig has became a multifunctional helper function,
rename it to virNetDevParseVfInfo.
Signed-off-by: zhenwei pi
Reviewed-by: Laine Stump
and pushed. Now I need to figure out what the prize is for answering
virDomainInterfaceStatsPtr stats)
+ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
+
G_DEFINE_AUTOPTR_CLEANUP_FUNC(virNetDevRxFilter, virNetDevRxFilterFree);
I'm unable to test on a system that has interface stats, but am assuming
that you have :-).
This looks fine to me, so:
Reviewed-by: Laine Stump
and pushed. Thanks for your contribution!
devices
qemu: add vhost-vdpa capability
qemu: add vdpa support
qemu: add monitor functions for handling file descriptors
qemu: support hotplug of vdpa devices
Include vdpa devices in node device list
Reviewed-by: Laine Stump for 1-5
For patch 6 (the nodedev XML additions) I'm
On 10/16/20 11:37 AM, Lentes, Bernd wrote:
Hi,
i have some questions concerning the destroying of domains, and i hope i'm
right here. If not sorry for the disturbance.
I'm running a two node HA cluster with pacemaker and KVM domains as resources.
>From time to time when i try to stop a domain
ago when I split all the unplug stuff into two
pieces, and factored out some common code used by all different device
types. See commit dd60bd62d and surrounding commits if you're interested...)
Reviewed-by: Laine Stump and pushed.
Signed-off-by: Jonathon Jongsma
---
src/qemu
say to do this, but the syntax-check doesn't check it)
Reviewed-by: Laine Stump
return NULL;
slirp = qemuSlirpNew();
etDevVFInterfaceStats(>source.subsys.u.pci.addr, stats) < 0)
goto cleanup;
...
Does all of that make sense? (Hopefully I haven't skipped over something
crucial).
On 9/30/20 11:06 AM, Laine Stump wrote:
On 9/24/20 4:18 AM, zhenwei pi wrote:
Collect PCI passth
(virSecretPtr, virHashSize(secretobjs->objs));
+data.secrets = g_new0(virSecretPtr, virHashSize(secretobjs->objs) + 1);
virHashForEach(secretobjs->objs, virSecretObjListExportCallback, );
virObjectRWUnlock(secretobjs);
Reviewed-by: Laine Stump
d(devs);
if (devices)
-data.devices = g_new0(virNodeDevicePtr, virHashSize(devs->objs));
+data.devices = g_new0(virNodeDevicePtr, virHashSize(devs->objs) + 1);
virHashForEach(devs->objs, virNodeDeviceObjListExportCallback, );
virObjectRWUnlock(devs);
Reviewed-by: Laine Stump
by a stack allocation
==15421==at 0x1175D2: networkDnsmasqConfContents (bridge_driver.c:1056)
All callers expect the function to initialize the structure
fully.
Signed-off-by: Michal Privoznik
Reviewed-by: Laine Stump
Did you see actual errors caused by this, or just the valgrind
complaints
On 10/8/20 4:54 AM, Steven Newbury wrote:
On Wed, 2020-10-07 at 21:45 -0400, Laine Stump wrote:
It is *definitely* less hacky to use than to carry
your own local patch on top of the libvirt source, which would force
you to always build your own libvirt binaries, and rebase your patch
every
On 10/7/20 5:44 PM, Steven Newbury wrote:
On Wed, 2020-10-07 at 13:17 -0600, Alex Williamson wrote:
Are you aware that you can add arbitrary options to devices using the
support in libvirt? For example:
...
...
...
smaller.
Signed-off-by: Pino Toscano
Reviewed-by: Laine Stump
---
src/esx/esx_driver.c | 20 +++-
src/esx/esx_util.c | 11 +++
src/esx/esx_util.h | 3 +--
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
On 10/5/20 7:41 AM, Pino Toscano wrote:
Call freeaddrinfo() as soon as @result is not needed anymore, i.e. right
after getnameinfo(); this avoids calling freeaddrinfo() in two branches.
Signed-off-by: Pino Toscano
Reviewed-by: Laine Stump
---
src/esx/esx_util.c | 4 +---
1 file
On 10/1/20 5:08 PM, Jonathon Jongsma wrote:
On Tue, 29 Sep 2020 15:53:39 -0400
Laine Stump wrote:
+
+if (vdpafdset < 0) {
+VIR_WARN("Cannot determine fdset for vdpa device");
+} else {
+if (qemuMonitorRemoveFdset(priv->mon
On 10/1/20 4:06 AM, Michal Prívozník wrote:
On 10/1/20 1:14 AM, Laine Stump wrote:
Lack of this one function (which is called for each active tap device
every time libvirtd is started) is the one thing preventing a
"WITHOUT_LIBNL" build of libvirt from being useful. With this
On 10/1/20 11:04 AM, Pavel Hrdina wrote:
We should also remove the 'virtualport' option from meson_options.txt .
Ah, okay. I hadn't been aware of that file. Fortunately my final sanity
builds were delayed while dealing with the daily "school issues", so I
haven't pushed yet :-)
On 10/1/20 4:06 AM, Michal Prívozník wrote:
On 10/1/20 1:14 AM, Laine Stump wrote:
IFLA_VF_MAX was introduced to the Linux kernel in 2.6.35, and was even
backported to the RHEL*6* 2.6.32 kernel downstream, so it is present
in all supported versions of all Linux distros that libvirt builds
years.
Signed-off-by: Laine Stump
---
meson.build | 4
src/util/virnetdevmacvlan.c | 5 -
2 files changed, 9 deletions(-)
diff --git a/meson.build b/meson.build
index 073ea6d49e..5e0af76bbc 100644
--- a/meson.build
+++ b/meson.build
@@ -1172,10 +1172,6 @@ if not get_option
to conditionalize any piece of code on
presence of IFLA_VF_MAX - if the platform is Linux, it is supported.
Signed-off-by: Laine Stump
---
src/util/virnetdev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index e1a4cc2bef
compilation
should be changed to #if defined(__linux__). However, the astute
reader will notice that the code in question is sending and receiving
netlink messages, so it really should be conditional on WITH_LIBNL
(which implies __linux__) instead, so that's what this patch does.
Signed-off-by: Laine
it on a non-Linux platform).
Signed-off-by: Laine Stump
---
meson.build | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/meson.build b/meson.build
index 5e0af76bbc..fe08a45b46 100644
--- a/meson.build
+++ b/meson.build
@@ -1159,20 +1159,15 @@ libxml_dep = dependency
, but possibly
there is a non-Linux platform that *does* have it...)
Signed-off-by: Laine Stump
---
meson.build | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meson.build b/meson.build
index a6b6f2d2ee..fa19677fee 100644
--- a/meson.build
+++ b/meson.build
@@ -774,9 +774,6 @@ symbols
netlink messages,
and any netlink interaction in libvirt requires libnl. So what we
*really* need is to check WITH_LIBNL (which itself implies __linux__,
as libnl is only useful/available on Linux).
Signed-off-by: Laine Stump
---
libvirt.spec.in | 1 -
meson.build
WITH_LIBNL will only be defined on Linux platforms (because libnl is a
library written to encapsulate parts of netlink, which is a Linux-only
API), so it's redundant to write:
#if defined(__linux__) && defined(WITH_LIBNL)
We can just check for WITH_LIBNL.
Signed-off-by: Laine Stump
useful it is in that state is a separate issue :-)
Signed-off-by: Laine Stump
---
src/util/virnetdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index 737081a12b..5221bada7b 100644
--- a/src/util/virnetdev.c
+++ b/src/util
ways) build on a system that doesn't have
libnl3-devel installed (7-8) (macvtap and interface type='hostdev'
don't work, but standard tap devices do), and removes a duplicated
identifier check that I noticed in meson.build (9).
Laine Stump (9):
util: remove useless check for IFLA_VF_MAX
util
Lack of this one function (which is called for each active tap device
every time libvirtd is started) is the one thing preventing a
"WITHOUT_LIBNL" build of libvirt from being useful. With this
alternate implementation, guests using standard tap devices will work
properly.
Signed-off
This function is no longer used anywhere except virDomainNetDefFree(),
so just inline its contents there.
Signed-off-by: Laine Stump
---
src/conf/domain_conf.c | 9 +
src/conf/domain_conf.h | 1 -
src/libvirt_private.syms | 1 -
3 files changed, 1 insertion(+), 10 deletions(-)
diff
All these lines were moved over from the now-defunct
virDomainNetDefClear(), which required all pointers to be cleared
after free, but virDomainNetDefFree() doesn't have that restriction -
after free'ing the pointers are never again referenced, so g_free() is
safe.
Signed-off-by: Laine Stump
, since this is the only real use)
Signed-off-by: Laine Stump
---
src/qemu/qemu_driver.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index b27f05992b..19e2aff3e4 100644
--- a/src/qemu
()
to g_free() (now that it's safe to do so).
Laine Stump (3):
qemu: eliminate use of virDomainNetDefClear() in
qemuConnectDomainXMLToNative()
conf: eliminate virDomainNetDefClear()
conf: use g_free() instead of VIR_FREE in virDomainNetDefFree()
src/conf/domain_conf.c | 51
On 9/30/20 4:29 PM, Jonathon Jongsma wrote:
So after after a little more thinking and poking it looks like it may
not be too hard to connect the sysfs path to the chardev after all. I
don't have any vdpa hardware at the moment, but for vdpa_sim, the sysfs
path /sys/devices/vdpa0 has a
On 9/24/20 4:18 AM, zhenwei pi wrote:
Collect PCI passthrough net device stats from kernel by netlink
API.
Currently, libvirt can not get PCI passthrough net device stats,
run command:
#virsh domifstat instance --interface=52:54:00:2d:b2:35
error: Failed to get interface stats instance
On 9/24/20 5:45 PM, Jonathon Jongsma wrote:
vDPA network devices allow high-performance networking in a virtual machine by
providing a wire-speed data path. These devices require a vendor-specific host
driver but the data path follows the virtio specification.
The support for vDPA devices was
On 9/24/20 5:45 PM, Jonathon Jongsma wrote:
The current udev node device driver ignores all events related to vdpa
devices. Since libvirt now supports vDPA network devices, include these
devices in the device list.
Can you provide an example in the commit log of what the output xml
looks
ce-vdpa.xml
@@ -0,0 +1,4 @@
+
+
+
+
diff --git
a/tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-vdpa.xml
b/tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-vdpa.xml
new file mode 100644
index 00..066180bb3c
--- /dev/null
+++ b/tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-vdpa.xml
@@ -0,0 +1,57 @@
+
+ hotplug
+ d091ea82-29e6-2e34-3005-f02617b36e87
+ 4194304
+ 4194304
+ 4
+
+hvm
+
+
+
+
+
+
+
+
+ destroy
+ restart
+ restart
+
+/usr/bin/qemu-system-x86_64
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
With the ExitMonitor() added where indicated, consideration of possibly
failing if the fd can't be deleted, and (as with the rest of the series)
as long as it's been possible to test with real hardware:
Reviewed-by: Laine Stump
On 9/25/20 2:30 PM, Mark Mielke wrote:
On Fri, Sep 25, 2020 at 4:35 AM Daniel P. Berrangé
mailto:berra...@redhat.com>> wrote:
If you have the tarball you can trivially generate the source RPM if
you need it because the tarball still contains the .spec file. IOW
just run
$
On 8/28/20 6:53 AM, Dmytro Linkin wrote:
Current virPCIGetNetName() logic is to get net device name by checking
it's phys_port_id, if caller provide it, or by it's index (eg, by it's
position at sysfs net directory). This approach worked fine up until
linux kernel version 5.8, where NVIDIA
(Please don't Cc individual developers in patch submissions unless
they've specifically asked you to do so)
On 9/21/20 8:25 AM, zhenwei pi wrote:
Collect PCI passthrough net device stats from kernel by netlink
API.
Currently, libvirt can not get PCI passthrough net device stats,
run command:
derp! :-O
On 9/14/20 7:03 AM, Ján Tomko wrote:
Signed-off-by: Ján Tomko
Fixes: 95089f481e003d971fe0a082018216c58c1b80e5
---
Pushed as trivial.
src/util/virnetdevtap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c
. They should keep in mind that when they
*do* make the devices migratable, there will need to be a way for
libvirt to discover that.
I would be okay with pushing this, as long as it has been tested on real
world equipment. Assuming that (but waiting for a response):
Reviewed-by: Laine Stump
.
Reviewed-by: Laine Stump
(with the small error messages fixed and demonstrating that it works
with a device)
src/qemu/qemu_command.c | 30 +--
src/qemu/qemu_command.h | 3 +-
src/qemu/qemu_domain.c| 6 ++-
src
On 9/11/20 1:08 PM, Laine Stump wrote:
On 9/11/20 7:34 AM, Ian Wienand wrote:
The original motivation for adding virNetDevIPCheckIPv6Forwarding
(00d28a78b5d1f6eaf79f06ac59e31c568af9da37) was that networking routes
would disappear when ipv6 forwarding was enabled for an interface
still I still might, but in this case it sounds like we'll have to
continue to use /proc.
So,
Reviewed-by: Laine Stump
(pending successful completion of CI (see below) and verification that
the error is triggered when appropriate. Once I've verified those two,
I'll push it).
Thanks
On 9/10/20 8:35 AM, Martin Kletzander wrote:
On Thu, Sep 10, 2020 at 01:56:53PM +0200, Pino Toscano wrote:
A lot of virReportError() calls use VIR_ERR_INTERNAL_ERROR to represent
the number of the error, even in cases where there is one fitting more.
Hence, replace some of them with better
On 9/9/20 2:38 AM, Cedric Bosdonnat wrote:
On Wed, 2020-09-09 at 12:39 +1000, Ian Wienand wrote:
On Tue, Sep 01, 2020 at 08:27:47AM +, Cedric Bosdonnat wrote:
So the hypervisor has at least one (Router Advertised) RA route.
After defining a network like the following, the RA route is
On 9/7/20 10:58 AM, Tim Wiederhake wrote:
This enables us to use g_auto* macros on those types.
Signed-off-by: Tim Wiederhake
---
src/cpu/cpu_ppc64.c | 91 +
danielhb had sent similar patches for this file last week, which I had
planned to
On 9/4/20 11:57 AM, Jiri Denemark wrote:
On Fri, Sep 04, 2020 at 10:58:45 +0200, Martin Kletzander wrote:
T...
@@ -3684,6 +3715,14 @@ qemuMigrationSrcRun(virQEMUDriverPtr driver,
if (migrate_flags & (QEMU_MONITOR_MIGRATE_NON_SHARED_DISK |
t), we can just remove the wait.
Laine Stump (2):
network: don't wait for IPv6 DAD completion when starting a network
util: remove unused virNetDevIPWaitDadFinish()
src/libvirt_private.syms| 1 -
src/network/bridge_driver.c | 32 --
src/util/virnetdevip.c
Since we no longer need to wait for IPv6 DAD to complete, we never
call this function.
Signed-off-by: Laine Stump
---
src/libvirt_private.syms | 1 -
src/util/virnetdevip.c | 119 ---
src/util/virnetdevip.h | 2 -
3 files changed, 122 deletions
it is first started, DAD never completes, leading to failure to start
any IPv6 network.
So, yes, this patch removes the wait for DAD completion, and IPv6
networks can once again start, and their associated dnsmasq process
starts successfully (this is the problem that the DAD wait was
originally intended
file);
return -1;
}
-next = item.target;
+g_free(next);
I recall once being reprimanded for calling g_free on a g_autofree()
pointer (by someone who said that *they* had been reprimanded for same).
I will say
Reviewed
On 9/4/20 4:24 AM, Michal Privoznik wrote:
In the past we had to declare @cfg and then explicitly unref it.
But now, with glib we can use g_autoptr() which will do the unref
automatically and thus is more bulletproof.
Signed-off-by: Michal Privoznik
Reviewed-by: Laine Stump
Reviewed-by: Laine Stump
On 9/3/20 9:33 AM, Daniel P. Berrangé wrote:
Signed-off-by: Daniel P. Berrangé
A bit of verbosity in error messages never hurt anyone.
Reviewed-by: Laine Stump
---
src/util/virnetdev.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions
this morning I was grepping for " HAVE_" and " WITH_" in
/usr/include, saw a couple of "config.h"s shoot past, and thought "Hmm.
That doesn't seem right! Surely those packages didn't *really* intend to
ship their config.h with their -dev package".
Reviewed-b
On 9/3/20 4:24 AM, Michal Privoznik wrote:
As it turned out my previous commits which switched from HAVE_ to
WITH_ and dropped stdarg.h detection were a bit too aggressive.
Because of reasons described in 9ea3424a178 we need to define
HAVE_STDARG_H before including readline otherwise macos build
On 9/3/20 10:58 AM, Daniel P. Berrangé wrote:
On Thu, Sep 03, 2020 at 10:56:25AM -0400, Laine Stump wrote:
On 9/3/20 9:34 AM, Daniel P. Berrangé wrote:
A long time ago we introduced a dummy tap device (e.g. virbr0-nic) that
we attached to the bridge device created for virtual networks
On 9/3/20 9:34 AM, Daniel P. Berrangé wrote:
A long time ago we introduced a dummy tap device (e.g. virbr0-nic) that
we attached to the bridge device created for virtual networks:
commit 5754dbd56d4738112a86776c09e810e32f7c3224
Author: Laine Stump
Date: Wed Feb 9 03:28:12 2011 -0500
On 9/2/20 3:25 PM, Jonathon Jongsma wrote:
Enable for qemu domains. This provides basic
support and does not support hotplug or migration.
Is there something specifically preventing hotplug, or you just haven't
implemented it yet?
(How does that work with FD passing, anyway? I haven't
.
With that fixed,
Reviewed-by: Laine Stump
Signed-off-by: Jonathon Jongsma
---
src/qemu/qemu_capabilities.c | 4
src/qemu/qemu_capabilities.h | 3 +++
tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 +
3 files changed, 8 insertions(+)
diff
t;, NONE);
+DO_TEST("net-vdpa", NONE);
DO_TEST("serial-tcp-tlsx509-chardev", NONE);
DO_TEST("serial-tcp-tlsx509-chardev-notls", NONE);
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 36581d2c31..7949acff09 100644
--- a/tools/virsh-domain.c
+++ b/tools
On 9/2/20 3:45 PM, Jonathon Jongsma wrote:
Rather than use the names "fial" and "kep", use "fail" and "keep". In
the DO_TEST() macro, to prevent the preprocessor replacing the struct
member names during assignment, use the names "fail_" and
r qemuInterfacePrepareSlirp(virQEMUDriverPtr driver,
virDomainNetDefPtr net);
+bool qemuInterfaceIsVnetCompatModel(const virDomainNetDef *net);
Reviewed-by: Laine Stump
I made the cosmetic changes I noted above (plus those noticed by
Daniel), and pushed the patch. Thanks for yo
Signed-off-by: Laine Stump
---
NEWS.rst | 8
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 748ee3b1df..64c2b3f581 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -100,6 +100,14 @@ v6.7.0 (unreleased)
implementation. But the implementation did not handle kernels
On 8/28/20 12:36 PM, Ján Tomko wrote:
[off-list]
On a Friday in 2020, Jiri Denemark wrote:
I have just tagged v6.7.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Does it seem to work in your limited testing?
You need to stop living in
-by: Michal Privoznik
Signed-off-by: Laine Stump
---
meson.build | 3 +++
src/util/meson.build | 1 +
2 files changed, 4 insertions(+)
diff --git a/meson.build b/meson.build
index dabd4196e6..81668a6681 100644
--- a/meson.build
+++ b/meson.build
@@ -1176,6 +1176,9 @@ endif
libxml_version
On 8/26/20 9:00 AM, Michal Privoznik wrote:
On 8/26/20 7:22 AM, Laine Stump wrote:
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name
own
parameterized template name (e.g. "mytap%d") in the XML, and libvirt
will just pass that through to the kernel as it always has.)
Signed-off-by: Laine Stump
---
src/libvirt_private.syms | 1 +
src/qemu/qemu_process.c | 20 +++-
src/util/virnetdevtap.c | 108 +
would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.
Signed-off-by: Laine Stump
---
src
, and standard tap where it overflow the 32 bit int first) with a
one-off build that started the counter just a few below the overflow
point, and it does work correctly.)
Laine Stump (2):
util: replace macvtap name reservation bitmap with a simple counter
util: assign tap device names using
On 8/24/20 6:28 PM, Daniel Henrique Barboza wrote:
On 8/23/20 1:52 AM, Laine Stump wrote:
Back when macvtap support was added in commit 315baab9443 in Feb. 2010
(libvirt-0.7.7), it was setup to autogenerate a name for the device if
one wasn't supplied, in the pattern "macvtap%d" (o
On 8/24/20 6:30 PM, Daniel Henrique Barboza wrote:
On 8/23/20 1:51 AM, Laine Stump wrote:
Back when the original version of this chunk of code was added (commit
41b087198 in libvirt-0.8.1 in April 2010), we used virExecDaemonize()
to start the qemu process, and would continue
On 8/24/20 6:23 AM, Michal Privoznik wrote:
On 8/24/20 6:23 AM, Laine Stump wrote:
When these functions are called from within virnetdevmacvlan.c, they
are usually called with virNetDevMacVLanCreateMutex held, but when
virNetDevMacVLanReserveName() is called from other places (hypervisor
. This locking version *is* called
from within virnetdevmacvlan.c, since there are a couple places that
we used to call the unlocked version after the lock was already
released.)
Signed-off-by: Laine Stump
---
src/util/virnetdevmacvlan.c | 42 ++---
1 file changed, 34
be a bit surprised to now see
vnet39283 or macvtap735. It has been pointed out to me that the same
thing happened with PIDs a few years ago, and while it looked strange
at first, everyone is now accustomed to it.
Laine Stump (3):
util: make locking versions of virNetDevMacVLan(Reserve|Release)Name
d instead use a "hopefully never-before
used number" algorithm.
(NB: It is still possible for a user to provide their own
parameterized template name (e.g. "mytap%d") in the XML, and libvirt
will just pass that through to the kernel as it always has.)
Signed-off-by: Laine Stump
;ID reservation" system (I'm thinking about
making a followup that gets rid of the bitmap, as it's now overkill
and just serves to make the code more confusing).
Signed-off-by: Laine Stump
---
src/util/virnetdevmacvlan.c | 67 +++--
1 file changed, 50 inserti
all nwfilter teardowns to
happen "before tap device deletion" is a fruitless pursuit, because a
tap device could be deleted by the qemu process being terminated
external to libvirt, i.e. we must instead avoid re-using tap device
names. That is coming.)
Signed-off-by: Laine Stump
---
src/
the code in both interface
parsing and formatting consistent for "vnetX", "macvtapX", and
"macvlanX", we can thus make sure that the autogenerated (and unneeded
/ completely *not* wanted) macvtap device name will not be sent with
the migration XML. This way when a mi
On 8/18/20 2:37 PM, Jonathon Jongsma wrote:
vDPA network devices allow high-performance networking in a virtual
machine by providing a wire-speed data path. These devices require a
vendor-specific host driver but the data path follows the virtio
specification.
The support for vDPA devices was
it is a valid configuration. The L1
cache under node #0 is still present.
Fixes: f0611fe8830
Signed-off-by: Michal Privoznik
---
Is this trivial enough to be pushed as such? ;-)
It looks pretty trivial to me, but just in case you want it:
Reviewed-by: Laine Stump
src/conf/numa_conf.c | 2
Yay! A user who follows up their conversation on the libvirt-users list
with a patch! :-)
On 8/11/20 8:14 PM, Ian Wienand wrote:
The checks modified here were added with
00d28a78b5d1f6eaf79f06ac59e31c568af9da37 to avoid losing routes on
hosts.
I'm Cc'ing the author of that patch, Cédric
On 8/7/20 3:46 PM, Patrick J. Magauran wrote:
On Fri, 2020-08-07 at 17:16 +0100, Daniel P. Berrangé wrote:
On Thu, Aug 06, 2020 at 10:53:32PM -0400, Patrick Magauran wrote:
Libvirt bases its decision about whether to apply the vnet_hdr flag
to the tap interface on whether or not the selected
On 8/4/20 5:09 AM, Daniel P. Berrangé wrote:
On Mon, Aug 03, 2020 at 07:29:19PM +0200, Peter Krempa wrote:
On Mon, Aug 03, 2020 at 19:18:53 +0200, Ján Tomko wrote:
Signed-off-by: Ján Tomko
---
src/util/virbitmap.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
On 8/3/20 1:29 PM, Peter Krempa wrote:
On Mon, Aug 03, 2020 at 19:18:53 +0200, Ján Tomko wrote:
Signed-off-by: Ján Tomko
---
src/util/virbitmap.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/util/virbitmap.c b/src/util/virbitmap.c
index
m, def))
goto endjob;
-}
xml = qemuDomainDefFormatLive(driver, priv->qemuCaps, def, NULL,
true, true);
} else {
xml = qemuDomainDefFormatLive(driver, priv->qemuCaps, vm->def,
This looks good now.
Reviewed-by: Laine Stump
(and pushed)
Be
On 7/28/20 9:56 PM, Chuan Zheng wrote:
From: Zheng Chuan
virDomainDefPtr 'def' is forgot to free after qemuDomainDefFormatLive(), fix it.
Signed-off-by: Zheng Chuan
---
src/qemu/qemu_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_driver.c
On 7/28/20 4:46 PM, Daniel Henrique Barboza wrote:
On 7/28/20 12:03 PM, Paulo de Rezende Pinatti wrote:
Context:
Libvirt can already detect the active VFs of an SRIOV PF device
specified in a network definition and automatically assign these VFs
to guests via an entry referring to that
++-
tests/bhyvexml2argvtest.c | 33 ++-
tests/bhyvexml2xmltest.c | 6 ++---
3 files changed, 31 insertions(+), 55 deletions(-)
Series
Reviewed-by: Laine Stump
(+), 272 deletions(-)
Series
Reviewed-by: Laine Stump
/commandtest.c | 327 ++--
1 file changed, 105 insertions(+), 222 deletions(-)
For the series:
Reviewed-by: Laine Stump
On 7/28/20 7:32 AM, Daniel Henrique Barboza wrote:
On 7/28/20 6:16 AM, Paulo de Rezende Pinatti wrote:
Signed-off-by: Paulo de Rezende Pinatti
---
docs/formatnode.html.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in
On 7/27/20 2:58 AM, Peter Krempa wrote:
On Fri, Jul 24, 2020 at 11:23:58 -0500, Jonathon Jongsma wrote:
On Thu, 2020-07-23 at 15:21 +0200, Peter Krempa wrote:
Start splitting the massive document into smaller pieces using the
.. include:: directive.
Signed-off-by: Peter Krempa
---
701 - 800 of 6183 matches
Mail list logo
