On Wed, Jul 29, 2020 at 01:12:55PM -0600, Alex Williamson wrote:
> On Wed, 29 Jul 2020 12:28:46 +0100
> Sean Mooney wrote:
>
> > On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > > On Mon, 27 Jul 2020 15:24:40 +0800
On Wed, Jul 29, 2020 at 12:28:46PM +0100, Sean Mooney wrote:
> On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > On Mon, 27 Jul 2020 15:24:40 +0800
> > > Yan Zhao wrote:
> > >
> > > > > > As you indicate, the vendor
Ping.
>
> Shmem device support property role with 'master'(master=on) or
> 'peer'(master=off, default mode), which controls to copy the
> shared memory on migration to the destination host or not. see
> https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/system/ivshmem.rst;hb=HEAD
>
>
> The
Thanks for your review.
I'll remind myself and follow the libvirt coding style in future work:)
-Original Message-
From: Laine Stump [mailto:la...@redhat.com]
Sent: 2020年7月30日 3:52
To: libvir-list@redhat.com
Cc: zhengchuan ; fangying ;
Chenzhendong (alex) ; wanghao (O)
; Zhanghailiang
On 7/28/20 11:42 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 | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git
On Wed, 29 Jul 2020 12:28:46 +0100
Sean Mooney wrote:
> On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > On Mon, 27 Jul 2020 15:24:40 +0800
> > > Yan Zhao wrote:
> > >
> > > > > > As you indicate, the vendor
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Mon, 27 Jul 2020 15:24:40 +0800
> Yan Zhao wrote:
>
> > > > As you indicate, the vendor driver is responsible for checking version
> > > > information embedded within the migration stream. Therefore a
> > > > migration should fail early
On a Wednesday in 2020, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
That's the way it should've been all the time. It was originally the case, but
then the rework to virFileFlock() made the function ambiguous when it was
created in commit 5a0a5f7fb5f5,
If a Ctrl-C arrives while we are in the middle of executing the
virDomainCreateXML call, we will have no "virDomainPtr" object
available, but QEMU may none the less be running.
This means we'll never try to stop the QEMU process before we
honour the Ctrl-C and exit.
To deal with this race we
On Wed, 2020-07-29 at 15:10 +0200, Martin Kletzander wrote:
> On Wed, Jul 29, 2020 at 02:20:50PM +0200, Andrea Bolognani wrote:
> > Also, since AFAIU resctrl is Linux-only, perhaps a better
> > preprocessor guard would be
> >
> > #ifdef __linux__
> >
> > so that we (correctly) stub the
There is a race between vir_event_thread_finalize and
virEventThreadWorker in releasing the last reference on
the GMainContext. If virEventThreadDataFree() runs after
vir_event_thread_finalize releases its reference, then
it will release the last reference on the GMainContext.
As a result
The source ID number is an alternative way to identify a source that has
been added to a GMainContext. Internally when a source ID is given, glib
will lookup the corresponding GSource and use that. The use of a source
ID is racy in some cases though, because it is invalid to continue to
use an ID
A while ago Cole reported that libvirt is exposing a long
term bug in GLib's event loop that results in non-deterministic
crashes:
https://www.redhat.com/archives/libvir-list/2020-February/msg00422.html
I kept forgetting to investigate it until now.
Daniel P. Berrangé (2):
util: keep track
There is a fairly long standing race condition bug in glib which can hit
if you call g_source_destroy or g_source_unref from a non-main thread:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1358
Unfortunately it is really common for libvirt to call g_source_destroy
from a non-main
On Wed, Jul 29, 2020 at 05:32:45PM +0200, Michal Privoznik wrote:
> On 7/29/20 4:38 PM, Pavel Hrdina wrote:
> >
>
> Maybe this was discussed already, but if not: do we want to have a script
> that would bundle meson + ninja commands, so that we could just
> "./build_and_dont_bother_me.sh". The
On 7/29/20 4:38 PM, Pavel Hrdina wrote:
>
Maybe this was discussed already, but if not: do we want to have a
script that would bundle meson + ninja commands, so that we could just
"./build_and_dont_bother_me.sh". The advantage would be that we could
set some defaults, just like we're doing
On Mon, Jul 27, 2020 at 11:02:10 -0400, Laine Stump wrote:
> 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
The second time around I will not post the complete series as it doesn't
make that much sense. Instead I'll post a diff between the two series to
provide the changes between these series together with links to both
versions pushed to gitlab repository.
Patches for v2 are available from my gitlab
On 7/7/20 9:46 PM, Michal Privoznik wrote:
Polite ping?
On Wed, Jul 29, 2020 at 02:20:50PM +0200, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
+++ b/src/util/virresctrl.c
@@ -456,6 +456,8 @@ VIR_ONCE_GLOBAL_INIT(virResctrl);
static int
virResctrlLockWrite(void)
{
+#ifndef WIN32
+
int fd =
On Wed, Jul 29, 2020 at 02:35:01PM +0200, Ján Tomko wrote:
On a Wednesday in 2020, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
+++ b/src/util/virresctrl.c
@@ -456,6 +456,8 @@ VIR_ONCE_GLOBAL_INIT(virResctrl);
static int
virResctrlLockWrite(void)
{
On Wed, Jul 29, 2020 at 02:09:20PM +0200, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
That's the way it should've been all the time. It was originally the case, but
then the rework to virFileFlock() made the function ambiguous when it was
created in
On a Wednesday in 2020, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
+++ b/src/util/virresctrl.c
@@ -456,6 +456,8 @@ VIR_ONCE_GLOBAL_INIT(virResctrl);
static int
virResctrlLockWrite(void)
{
+#ifndef WIN32
+
int fd = open(SYSFS_RESCTRL_PATH,
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
> There is no distinction between Read/Write locks for resctrl from libvirt's
> point of view any more.
>
> Signed-off-by: Martin Kletzander
> ---
> src/util/virresctrl.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
> +++ b/src/util/virresctrl.c
> @@ -456,6 +456,8 @@ VIR_ONCE_GLOBAL_INIT(virResctrl);
> static int
> virResctrlLockWrite(void)
> {
> +#ifndef WIN32
> +
> int fd = open(SYSFS_RESCTRL_PATH, O_RDONLY | O_CLOEXEC);
>
> if (fd <
On Wed, 2020-07-29 at 13:43 +0200, Martin Kletzander wrote:
> That's the way it should've been all the time. It was originally the case,
> but
> then the rework to virFileFlock() made the function ambiguous when it was
> created in commit 5a0a5f7fb5f5, and due to that it was misused in commit
>
That's the way it should've been all the time. It was originally the case, but
then the rework to virFileFlock() made the function ambiguous when it was
created in commit 5a0a5f7fb5f5, and due to that it was misused in commit
657ddeff2313 and since then the lock being taken was shared rather than
v3:
- put the fixing code first, so it can be pushed in the freeze
- get rid of unnecessary code
- CI check: https://gitlab.com/nertpinx/libvirt/-/pipelines/172040463
v2:
- Split changes into separate patches
- https://www.redhat.com/archives/libvir-list/2020-July/msg00601.html
v1:
-
It was created to get rid of conditional compilation in the resctrl code and
make it usable anywhere else. However this is not something that is going to be
used in other places because it is not portable and resctrl is just very
specific in this regard. And there is no reason why there could
There is no distinction between Read/Write locks for resctrl from libvirt's
point of view any more.
Signed-off-by: Martin Kletzander
---
src/util/virresctrl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c
index
On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > On Mon, 27 Jul 2020 15:24:40 +0800
> > Yan Zhao wrote:
> >
> > > > > As you indicate, the vendor driver is responsible for checking version
> > > > > information embedded
On Wed, Jul 29, 2020 at 12:00:46PM +0200, Peter Krempa wrote:
> On Wed, Jul 29, 2020 at 11:47:31 +0200, Pavel Hrdina wrote:
> > On Wed, Jul 29, 2020 at 10:29:46AM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jul 29, 2020 at 09:11:11AM +0200, Pavel Hrdina wrote:
> > > > So I was trying to figure
On Wed, Jul 29, 2020 at 11:47:31 +0200, Pavel Hrdina wrote:
> On Wed, Jul 29, 2020 at 10:29:46AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jul 29, 2020 at 09:11:11AM +0200, Pavel Hrdina wrote:
> > > So I was trying to figure out what to do with our syntax-check and this
> > > could be one
On Wed, 2020-07-29 at 11:17 +0200, Ján Tomko wrote:
> On a Wednesday in 2020, Andrea Bolognani wrote:
> > Why are you limiting this change to a subset of the build jobs?
>
> It goes in line with the actual motivation mentioned in the commit
> message ;)
>
> That is: I wanted to get some
On Wed, 2020-07-29 at 11:02 +0200, Ján Tomko wrote:
> On a Wednesday in 2020, Andrea Bolognani wrote:
> > Also, based on the above, do you think we should have clang builds
> > on more platforms or are two Fedora builds giving us enough coverage?
>
> The intention was to use different versions of
On Wed, Jul 29, 2020 at 10:29:46AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 29, 2020 at 09:11:11AM +0200, Pavel Hrdina wrote:
> > So I was trying to figure out what to do with our syntax-check and this
> > could be one solution:
> >
> >
> > rc = run_command(
> > 'sed', '-n',
> >
Signed-off-by: Meina Li
---
docs/formatdomain.html.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index f3a639b972..394eab2897 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -4092,7 +4092,8
On Wed, Jul 29, 2020 at 09:11:11AM +0200, Pavel Hrdina wrote:
> So I was trying to figure out what to do with our syntax-check and this
> could be one solution:
>
>
> rc = run_command(
> 'sed', '-n',
> 's/^\\(sc_[a-zA-Z0-9_-]*\\):.*/\\1/p',
> meson.current_source_dir() / 'syntax-check.mk',
On a Wednesday in 2020, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
Make the pipeline chart more interesting.
Maybe include a short summary of the actual motivation here :)
+++ b/.gitlab-ci.yml
@@ -268,41 +268,49 @@ mingw64-fedora-rawhide-container:
On a Wednesday in 2020, Andrea Bolognani wrote:
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
Out of the Linux distros we build on in the CI, clang
is only available on Fedora.
Uh? I guess you based this claim on
https://repology.org/project/clang/versions
Yes.
but the
Turns out 'ldebian' was not a typo, but rather the result of
mistakenly shifting the dash in 'armv7l-debian' one spot to the
left.
Fixes: 821100e81281eef9beeb15c3f4bf6a000d6a03c5
Reported-by: Pavel Hrdina
Signed-off-by: Andrea Bolognani
---
Pushed as trivial.
.gitlab-ci.yml | 4 ++--
1 file
On Wed, 2020-07-29 at 10:30 +0200, Pavel Hrdina wrote:
> On Wed, Jul 29, 2020 at 10:24:01AM +0200, Andrea Bolognani wrote:
> > +++ b/.gitlab-ci.yml
> > @@ -178,7 +178,7 @@ armv6l-debian-10-container:
> >variables:
> > NAME: debian-10-cross-armv6l
> >
> > -armv7-ldebian-10-container:
> >
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
> Make the pipeline chart more interesting.
Maybe include a short summary of the actual motivation here :)
> +++ b/.gitlab-ci.yml
> @@ -268,41 +268,49 @@ mingw64-fedora-rawhide-container:
>
> x64-debian-10:
><<:
On Wed, Jul 29, 2020 at 10:24:01AM +0200, Andrea Bolognani wrote:
> Fixes: 95abbdc432133b9ae4a76d15251d64b5893717e6
> Signed-off-by: Andrea Bolognani
> ---
> Pushed as trivial.
>
> .gitlab-ci.yml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.gitlab-ci.yml
Fixes: 95abbdc432133b9ae4a76d15251d64b5893717e6
Signed-off-by: Andrea Bolognani
---
Pushed as trivial.
.gitlab-ci.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 702198ec8e..9d179648f0 100644
--- a/.gitlab-ci.yml
+++
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
> x64-freebsd-12-build:
><<: *cirrus_build_job_definition
> + needs: []
>variables:
> NAME: freebsd-12
> CIRRUS_VM_INSTANCE_TYPE: freebsd_instance
Since this applies to all Cirrus CI builds, we can set 'needs' in
On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> On Mon, 27 Jul 2020 15:24:40 +0800
> Yan Zhao wrote:
>
> > > > As you indicate, the vendor driver is responsible for checking version
> > > > information embedded within the migration stream. Therefore a
> > > > migration should
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
> Out of the Linux distros we build on in the CI, clang
> is only available on Fedora.
Uh? I guess you based this claim on
https://repology.org/project/clang/versions
but the information contained in that page is inaccurate: clang is
On 7/28/20 10:45 PM, Pavel Hrdina wrote:
Just a note, the file access testing is broken and it fails for a lot of
tests.
Yeah, I have patches for it, but I've never gotten around sending them.
Will do today.
Michal
On Wed, 2020-07-29 at 01:36 +0200, Ján Tomko wrote:
> We dropped ncurses and added libnuma-dev on all debian archs
> as of libvirt-ci commit:
>
> commit 4717287565d81b747d3176332108fe0302de2669
> projects: libvirt doesn't depend on ncurses
>
> Signed-off-by: Ján Tomko
> ---
>
On Wed, Jul 29, 2020 at 3:44 PM Meina Li wrote:
> Signed-off-by: Meina Li
> ---
> docs/formatdomain.html.in | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index f3a639b972..394eab2897 100644
> ---
On Tue, Jul 28, 2020 at 04:19:56PM +0200, Peter Krempa wrote:
> On Tue, Jul 28, 2020 at 15:08:11 +0100, Daniel Berrange wrote:
> > On Tue, Jul 28, 2020 at 04:04:39PM +0200, Pavel Hrdina wrote:
> > > On Tue, Jul 28, 2020 at 03:48:29PM +0200, Peter Krempa wrote:
> > > > On Thu, Jul 16, 2020 at
52 matches
Mail list logo
