From: Julio Faracco
Commit 72862797 introduced resolution settings for QEMU video drivers.
It includes a new structure inside video definition. So, the code needs
to clear pointer allocation for that structure into clear function
virDomainVideoDefClear(). This commit adds this missing
On Thu, Oct 17, 2019 at 07:57:46AM +0200, Peter Krempa wrote:
> On Wed, Oct 16, 2019 at 17:08:20 +0100, Daniel Berrange wrote:
> > On Wed, Oct 16, 2019 at 05:03:31PM +0200, Ján Tomko wrote:
> > > On Wed, Oct 16, 2019 at 02:22:56PM +0200, Andrea Bolognani wrote:
>
> [...]
>
> > > Here it deviates
I usually don't bother list with ordinary messages, but...
Thank you very much for your guidance and patience, Cole!
I appreciate it!
Em qui, 17 de out de 2019 às 17:25, Cole Robinson
escreveu:
>
> On 10/17/19 12:30 AM, jcfara...@gmail.com wrote:
> > From: Julio Faracco
> >
> > This serie adds
At least, I need to fix the leak problem. ;-)
I can grab other problems too.
I will submit a fix/patch soon.
--
Julio Faracco
Em qui, 17 de out de 2019 às 17:33, Cole Robinson
escreveu:
>
> My apologies Jonathan, I saw your responses after I reviewed and pushed
> Julio's patches. I need to
Remember when the MAC address of libvirt-created bridges weren't
stable, and changed as guests were started and stopped? Pepperidge
Farms remembers.
(No, I would never actually push a comment like that! Just wanted to
get your attention).
When libvirt first implemented a stable and configurable
From: Laine Stump
I just sent a single patch for this, then realized there was a small
prerequisite patch also needed. So 1/2 is the prerequisite patch, and 2/2 is
identical to the single patch I sent previously.
Laine Stump (2):
util: allow sending mac addr to virNetNewLink without ifindex
From: Laine Stump
Although until now, any use of the extra_args argument (a pointer to a
struct containing extra attributes to add the the RTM_NEWLINK message)
would always have the ifindex and mac set, so the code could assume it
was safe to add both to the message if extra_args != NULL. There
From: Laine Stump
Remember when the MAC address of libvirt-created bridges weren't
stable, and changed as guests were started and stopped? Pepperidge
Farms remembers.
(No, I would never actually push a comment like that! Just wanted to
get your attention).
When libvirt first implemented a
Sorry - disregard this patch by itself. There is a small prerequisite
patch that is needed along with it. I've resent this patch in a 2 patch
series that includes both.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 17, 2019 at 12:37 PM wrote:
> From: Julio Faracco
>
> This commit adds resolution element with parameters 'x' and 'y' into video
> XML domain group definition. Both, properties were added into an element
> called 'resolution' and it was added inside 'model' element. They are set
>
On 10/16/19 3:21 PM, Collin Walling wrote:
Providing an erroneous CPU definition in the XML file provided to the
hypervisor-cpu-compare/baseline command will result in a verbose
internal error. Let's add some sanity checking before executing the QMP
commands to provide a cleaner message if
On Thu, 2019-10-17 at 09:48 +0100, Daniel P. Berrangé wrote:
> On Thu, Oct 17, 2019 at 09:40:08AM +0200, Andrea Bolognani wrote:
> > On Wed, 2019-10-16 at 17:03 +0100, Daniel P. Berrangé wrote:
> The point of integrating with GitLab is to get the pre-merge
> checking of patches, instead of
...
>
> FWIW, when I'm writing Go code I have used emacs 'go-mode' and
> this runs 'go fmt' to automatically fix your style problems
> every time you save the file. So your code is basically always
> correct, and you don't need a separate job to check it later.
Since you mentioned ^this, we
On Thu, Oct 17, 2019 at 03:30:26PM +0200, Jiri Denemark wrote:
> On Thu, Oct 17, 2019 at 09:04:05 -0400, Cole Robinson wrote:
> > On 10/16/19 4:54 PM, Daniel Henrique Barboza wrote:
> > > This patch changes all virAsprintf calls to use the GLib API
> > > g_strdup_printf in qemu_driver.c
> > >
> >
Signed-off-by: Andrea Bolognani
---
docs/gitdm/companies/others | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/gitdm/companies/others b/docs/gitdm/companies/others
index db2c0061bd..428a373977 100644
--- a/docs/gitdm/companies/others
+++ b/docs/gitdm/companies/others
@@
A few new companies and individuals contributed to libvirt since
the last time the gitdm configuration was updated.
Signed-off-by: Andrea Bolognani
---
docs/gitdm/companies/others| 2 ++
docs/gitdm/groups/unaffiliated | 1 +
2 files changed, 3 insertions(+)
diff --git
On Thu, Oct 17, 2019 at 04:22:49PM +0200, Andrea Bolognani wrote:
> To me the Web-based workflow is inferior to the mail-based one, this
> opinion being informed by using GitHub regularly for the past two
> months or so. I'm willing to take hit if it can be proven that the
> drawbacks are
On 10/17/19 10:51 AM, Daniel P. Berrangé wrote:
On Thu, Oct 17, 2019 at 03:30:26PM +0200, Jiri Denemark wrote:
On Thu, Oct 17, 2019 at 09:04:05 -0400, Cole Robinson wrote:
On 10/16/19 4:54 PM, Daniel Henrique Barboza wrote:
This patch changes all virAsprintf calls to use the GLib API
Andrea Bolognani (2):
gitdm: Fix sorting
gitdm: Add missing entries
docs/gitdm/companies/others| 4 +++-
docs/gitdm/groups/unaffiliated | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
This patch changes all virAsprintf calls to use the GLib API
g_strdup_printf in qemu_process.c.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_process.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/src/qemu/qemu_process.c
> On 17 Oct 2019, at 14:35, Cole Robinson wrote:
>
> Hmm why wasn't I in to/cc list, was that intentional?
Not at all. I assumed a reply-to would add it automatically and did not
bother checking. Probably something wrong in my mu4e config.
>
> On 10/17/19 5:26 AM, Christophe de Dinechin
Well, this one didn't age well. I'll see if I can get a 'due dilligence'
going
in qemu_hotplug.c like I did with qemu_driver.c to replace it.
Thanks,
DHB
On 9/30/19 3:53 PM, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza
---
Checked other pointer types that can be
> The fork'd child process inherits all signal handlers from the parent.
> These handlers may no longer be valid since we are mass-closing all
> file descriptors. We thus need to kill off all the signal handlers
> in the forkd child.
>
> There's a window between fork & sigaction where signals can
On Mon, 14 Oct 2019 at 20:29, John Snow wrote:
>
> The following changes since commit c760cb77e511eb05094df67c1b30029a952efa35:
>
> Merge remote-tracking branch
> 'remotes/dgilbert/tags/pull-migration-20191011a' into staging (2019-10-14
> 16:09:52 +0100)
>
> are available in the Git
On Thu, Oct 17, 2019 at 6:13 AM Daniel P. Berrangé wrote:
>
> On Thu, Oct 17, 2019 at 11:06:25AM +0200, Michal Privoznik wrote:
> > On 10/16/19 1:22 PM, casan...@redhat.com wrote:
> > > From: Carlos Santos
> > >
> > > On musl libc "stderr" is a preprocessor macro whose expansion leads to
> > >
On Thu, Oct 17, 2019 at 09:02:08AM -0300, Carlos Santos wrote:
> On Thu, Oct 17, 2019 at 6:13 AM Daniel P. Berrangé
> wrote:
> >
> > On Thu, Oct 17, 2019 at 11:06:25AM +0200, Michal Privoznik wrote:
> > > On 10/16/19 1:22 PM, casan...@redhat.com wrote:
> > > > From: Carlos Santos
> > > >
> > >
Hmm why wasn't I in to/cc list, was that intentional?
On 10/17/19 5:26 AM, Christophe de Dinechin wrote:
>
> Cole Robinson writes:
>
>> This series is the first steps to teaching libvirt about qcow2
>> data_file support, aka external data files or qcow2 external metadata.
>>
>> A bit about the
On Thu, Oct 17, 2019 at 09:04:05 -0400, Cole Robinson wrote:
> On 10/16/19 4:54 PM, Daniel Henrique Barboza wrote:
> > This patch changes all virAsprintf calls to use the GLib API
> > g_strdup_printf in qemu_driver.c
> >
> > Signed-off-by: Daniel Henrique Barboza
> > ---
> >
On 10/17/19 9:10 AM, Michal Privoznik wrote:
On 10/16/19 10:54 PM, Daniel Henrique Barboza wrote:
String and other scalar pointers an be auto-unref, sparing us
a VIR_FREE() call.
This patch uses g_autofree whenever possible with strings and
other scalar pointer types.
Suggested-by: Erik
The g_auto*() changes made by the previous patches made a lot
of 'cleanup' labels obsolete. Let's remove them.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_process.c | 199
1 file changed, 77 insertions(+), 122 deletions(-)
diff --git
Change all feasible pointers to use g_autoptr().
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_process.c | 121 +---
1 file changed, 40 insertions(+), 81 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index
On 10/16/19 10:54 PM, Daniel Henrique Barboza wrote:
String and other scalar pointers an be auto-unref, sparing us
a VIR_FREE() call.
This patch uses g_autofree whenever possible with strings and
other scalar pointer types.
Suggested-by: Erik Skultety
Signed-off-by: Daniel Henrique Barboza
On 10/16/19 10:54 PM, Daniel Henrique Barboza wrote:
changes from v3:
- only use the new Glib macros in all patches
- different patch split, as suggested by Jano in v3 review
- patch 5 (new): g_strdup_printf conversion
changes from v2:
- rebased with newer master (67e72053c1)
- added an extra
changes from v2:
- only use GLib macros
- split the patches to separate the 'remove cleanup labels'
patch from the most trivial stuff
- added a new patch to change virAsprintf to g_stdup_printf
v2: https://www.redhat.com/archives/libvir-list/2019-October/msg00929.html
v1:
Change all strings and scalar pointers to use g_autofree.
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_process.c | 93 ++---
1 file changed, 32 insertions(+), 61 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index
On 10/16/19 4:54 PM, Daniel Henrique Barboza wrote:
> This patch changes all virAsprintf calls to use the GLib API
> g_strdup_printf in qemu_driver.c
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> src/qemu/qemu_driver.c | 38 +-
> 1 file changed, 17
On 10/17/19 10:04 AM, Cole Robinson wrote:
On 10/16/19 4:54 PM, Daniel Henrique Barboza wrote:
This patch changes all virAsprintf calls to use the GLib API
g_strdup_printf in qemu_driver.c
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_driver.c | 38
On Wed, Oct 16, 2019 at 6:42 PM Daniel Henrique Barboza <
danielhb...@gmail.com> wrote:
>
>
> On 10/16/19 9:22 AM, Andrea Bolognani wrote:
> > As we look to make the libvirt project easier to contribute to, one
> > fact that certainly comes to mind is that we only accept patches via
> > the
On Wed, 2019-10-16 at 17:03 +0100, Daniel P. Berrangé wrote:
> There's two tools being discussed here - both GitHub and GitLab.
> Splitting attention between email and a web based tool is bad,
> but splitting attention between email and two web based tools
> is even worse.
>
> Finally I have
On Thu, Oct 17, 2019 at 09:40:08AM +0200, Andrea Bolognani wrote:
> On Wed, 2019-10-16 at 17:03 +0100, Daniel P. Berrangé wrote:
> > There's two tools being discussed here - both GitHub and GitLab.
> > Splitting attention between email and a web based tool is bad,
> > but splitting attention
Cole Robinson writes:
> This series is the first steps to teaching libvirt about qcow2
> data_file support, aka external data files or qcow2 external metadata.
>
> A bit about the feature: it was added in qemu 4.0. It essentially
> creates a two part image file: a qcow2 layer that just tracks
Daniel Henrique Barboza writes:
> On 10/7/19 6:49 PM, Cole Robinson wrote:
>> >From qemu.git docs/interop/qcow2.txt
>
> Here's the '>' again. I think this is something you're using to cite an
> external source in the commit message. Is that it?
No, that is the way email "protects" lines that
On Thu, 2019-10-17 at 10:33 +0200, Martin Kletzander wrote:
> Another thing we completely missed (which could also be more
> effective) is to have a PR template [1] which would say "please open MRs on
> gitlab instead (or "we don't do GitHub" for current state).
Yup, that's definitely a good idea
These functions got a reference to the driver config
without actually using it:
processNicRxFilterChangedEvent
qemuConnectDomainXMLToNative
Signed-off-by: Ján Tomko
---
Pushed as trivial.
src/qemu/qemu_driver.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/qemu/qemu_driver.c
In few places we have the following code pattern:
int ret;
... /* @ret is not accessed here */
ret = f(...);
return ret;
This pattern can be written less verbose:
...
return f(...);
This patch was generated with following coccinelle spatch:
@@
type T;
constant C;
On 10/16/19 1:22 PM, casan...@redhat.com wrote:
From: Carlos Santos
- Do not use 'stderr' as a field name, since it's a preprocessor macro
in stdio.h.
- Include paths.h for _PATH_MOUNTED, if it's not defined in mntent.h.
Found while porting libvirt to Buildroot (https://buildroot.org/).
On Thu, Oct 17, 2019 at 11:06:25AM +0200, Michal Privoznik wrote:
> On 10/16/19 1:22 PM, casan...@redhat.com wrote:
> > From: Carlos Santos
> >
> > On musl libc "stderr" is a preprocessor macro whose expansion leads to
> > compilation errors:
>
> Indeed, from their stdio.h:
>
> #define stdin
On Thu, Oct 17, 2019 at 09:40:08AM +0200, Andrea Bolognani wrote:
On Wed, 2019-10-16 at 17:03 +0100, Daniel P. Berrangé wrote:
There's two tools being discussed here - both GitHub and GitLab.
Splitting attention between email and a web based tool is bad,
but splitting attention between email
On 10/16/19 4:24 PM, Ján Tomko wrote:
Make the GLib section more readable.
Ján Tomko (3):
docs: hacking: separate section about already deleted macros
docs: hacking: use for functions/names
docs: hacking: add a conversion table for removed libvirt macros
docs/hacking.html.in | 71
On 10/16/19 1:22 PM, casan...@redhat.com wrote:
From: Carlos Santos
On musl _PATH_MOUNTED is defined in paths.h, not in mntent.h, which
causes compilation errors:
storage/storage_backend_fs.c: In function
'virStorageBackendFileSystemIsMounted':
storage/storage_backend_fs.c:255:23: error:
On Thu, Oct 17, 2019 at 08:55:35AM +0200, Pavel Hrdina wrote:
> On Thu, Oct 17, 2019 at 07:57:46AM +0200, Peter Krempa wrote:
> > On Wed, Oct 16, 2019 at 17:08:20 +0100, Daniel Berrange wrote:
> > > On Wed, Oct 16, 2019 at 05:03:31PM +0200, Ján Tomko wrote:
> > > > On Wed, Oct 16, 2019 at
On 10/16/19 1:22 PM, casan...@redhat.com wrote:
From: Carlos Santos
On musl libc "stderr" is a preprocessor macro whose expansion leads to
compilation errors:
Indeed, from their stdio.h:
#define stdin (stdin)
#define stdout (stdout)
#define stderr (stderr)
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_hotplug.c | 50 +
1 file changed, 21 insertions(+), 29 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 39b6cade58..8a46df9946 100644
--- a/src/qemu/qemu_hotplug.c
The FOSDEM open source developer conference is taking place in
Brussels, Belgium on February 1st & 2nd, 2020. The call for
virtualization presentations has been posted[1]. Reposting the text
here (formatted for readability):
There is not much to do regarding cleanup and g_auto* in this
file. Here's a couple of simple fixes I've found.
changes from v1:
- added a new patch to remove unused cleanup labels
v1: https://www.redhat.com/archives/libvir-list/2019-September/msg01463.html
Daniel Henrique Barboza (2):
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_hotplug.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index bf301919cc..39b6cade58 100644
--- a/src/qemu/qemu_hotplug.c
+++
On 10/17/19 12:30 AM, jcfara...@gmail.com wrote:
> From: Julio Faracco
>
> This serie adds resolution ('x' and 'y') properties into XML definition
> for QEMU video devices to specify a default resolution. This specific
> case is not considering those attributes as a QEMU capabilities due to
>
On 9/26/19 12:11 PM, Michal Privoznik wrote:
> In some places we need to check if a hostdev has VFIO backend.
> Because of how complicated virDomainHostdevDef structure is, the
> check consists of three lines. Move them to a function and
> replace all checks with the function call.
>
>
On 9/26/19 12:11 PM, Michal Privoznik wrote:
> These functions do not change any of the passed hostdevs. They
> just read them.
>
> Signed-off-by: Michal Privoznik
> ---
> src/util/virhostdev.c | 6 +++---
> src/util/virhostdev.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
So, you're adding the support for parsing and formatting the new
resolution parameters in this patch, but you're not actually testing
them as part of this patch. The new tests that you add here have no
mention of these resolution parameters. So I think you should include
the changes to
On Thu, 2019-10-17 at 09:46 -0300, Daniel Henrique Barboza wrote:
> Change all feasible pointers to use g_autoptr().
>
> Signed-off-by: Daniel Henrique Barboza
> ---
> src/qemu/qemu_process.c | 121 +-
> --
> 1 file changed, 40 insertions(+), 81 deletions(-)
On 10/17/19 5:03 PM, Jonathon Jongsma wrote:
On Thu, 2019-10-17 at 09:46 -0300, Daniel Henrique Barboza wrote:
Change all feasible pointers to use g_autoptr().
Signed-off-by: Daniel Henrique Barboza
---
src/qemu/qemu_process.c | 121 +-
--
1 file
On Thu, 2019-10-17 at 17:08 -0300, Daniel Henrique Barboza wrote:
>
> On 10/17/19 5:03 PM, Jonathon Jongsma wrote:
> > On Thu, 2019-10-17 at 09:46 -0300, Daniel Henrique Barboza wrote:
> > > Change all feasible pointers to use g_autoptr().
> > >
> > > Signed-off-by: Daniel Henrique Barboza
> >
My apologies Jonathan, I saw your responses after I reviewed and pushed
Julio's patches. I need to remember to check my list mailbox for things
that are sitting in my inbox
On 10/17/19 3:12 PM, Jonathon Jongsma wrote:
> So, you're adding the support for parsing and formatting the new
> resolution
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> Since its introduction in v1.0.5-rc1-19-g6e13860cb4 the
> qemuTeardownHostdevCgroup() does nothing unless the passed
> hostdev is a PCI device with VFIO backend. This seems
> unnecessary.
>
> Signed-off-by: Michal Privoznik
> ---
>
On 9/26/19 12:11 PM, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik
> ---
> src/conf/domain_conf.c | 14 ++
> src/conf/domain_conf.h | 3 +++
> src/libvirt_private.syms | 1 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/src/conf/domain_conf.c
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> There are two types of host devices that require /dev/vfio/vfio
> access:
>
> 1) PCI devices with VFIO backend
> 2) Mediated devices
>
> Introduce a simple helper that returns true if passed @hostdev
> falls in either of the categories.
>
>
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_domain.c | 9 +
> src/qemu/qemu_domain.h | 2 ++
> 2 files changed, 11 insertions(+)
Reviewed-by: Cole Robinson
- Cole
--
libvir-list mailing list
libvir-list@redhat.com
On Thu, 2019-10-17 at 14:12 -0500, Jonathon Jongsma wrote:
> So, you're adding the support for parsing and formatting the new
> resolution parameters in this patch, but you're not actually testing
> them as part of this patch. The new tests that you add here have no
> mention of these resolution
On 10/17/19 7:07 AM, Peter Maydell wrote:
> On Mon, 14 Oct 2019 at 20:29, John Snow wrote:
>>
>> The following changes since commit c760cb77e511eb05094df67c1b30029a952efa35:
>>
>> Merge remote-tracking branch
>> 'remotes/dgilbert/tags/pull-migration-20191011a' into staging (2019-10-14
>>
On 10/16/19 12:22 PM, Jonathon Jongsma wrote:
> On Wed, 2019-10-16 at 09:12 -0300, Daniel Henrique Barboza wrote:
>>
>> On 10/15/19 1:01 PM, Cole Robinson wrote:
>>> When searching qemuCaps->domCapsCache for existing domCaps data,
>>> we check for a matching pair of arch+virttype+machine+emulator.
From: Vladimir Sementsov-Ogievskiy
qmp_block_dirty_bitmap_add and do_block_dirty_bitmap_remove do acquire
aio context since 0a6c86d024c52b. But this is not enough: we also must
lock qcow2 mutex when access in-image metadata. Especially it concerns
freeing qcow2 clusters.
To achieve this, move
From: Vladimir Sementsov-Ogievskiy
Drop meta bitmaps, as they are unused.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
include/block/dirty-bitmap.h | 5
block/dirty-bitmap.c
From: Vladimir Sementsov-Ogievskiy
mutex field is just a pointer to bs->dirty_bitmap_mutex, so no needs
to store it in BdrvDirtyBitmap when we have bs pointer in it (since
previous patch).
Drop mutex field. Constantly use bdrv_dirty_bitmaps_lock/unlock in
block/dirty-bitmap.c to make it more
From: Vladimir Sementsov-Ogievskiy
Firstly, no reason to optimize failure path. Then, function name is
ambiguous: it checks for readonly and similar things, but someone may
think that it will ignore normal bitmaps which was just unchanged, and
this is in bad relation with the fact that we should
From: Vladimir Sementsov-Ogievskiy
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs, like in recently fixed write-blocking mode of
mirror: user calls reset on unaligned region, not keeping in mind that
there are possible unrelated dirty bytes, covered
The following changes since commit f22f553efffd083ff624be116726f843a39f1148:
Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20191013' into
staging (2019-10-17 16:48:56 +0100)
are available in the Git repository at:
https://github.com/jnsnow/qemu.git tags/bitmaps-pull-request
for
From: Vladimir Sementsov-Ogievskiy
It's needed to fix reopening qcow2 with bitmaps to RW. Currently it
can't work, as qcow2 needs write access to file child, to mark bitmaps
in-image with IN_USE flag. But usually children goes after parents in
reopen queue and file child is still RO on qcow2
From: Vladimir Sementsov-Ogievskiy
block/dirty-bitmap.c seems to be more appropriate for it and
bdrv_remove_persistent_dirty_bitmap already in it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190920082543.23444-2-vsement...@virtuozzo.com
Signed-off-by: John
From: Vladimir Sementsov-Ogievskiy
bdrv_dirty_bitmap_next is always used in same pattern. So, split it
into _next and _first, instead of combining two functions into one and
add FOR_EACH_DIRTY_BITMAP macro.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id:
From: Vladimir Sementsov-Ogievskiy
Reopening bitmaps to RW was broken prior to previous commit. Check that
it works now.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190927122355.7344-4-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
tests/qemu-iotests/165 | 57
From: Vladimir Sementsov-Ogievskiy
We'll need reverse-foreach in the following commit, QTAILQ support it,
so move to QTAILQ.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
Message-id: 20190927122355.7344-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
From: Vladimir Sementsov-Ogievskiy
Add bs field to BdrvDirtyBitmap structure. Drop BlockDriverState
parameter from bitmap APIs where possible.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190916141911.5255-3-vsement...@virtuozzo.com
[Rebased on top of
From: Vladimir Sementsov-Ogievskiy
It's more comfortable to not deal with local_err.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190920082543.23444-3-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block/qcow2.h| 5 ++---
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> The @freeTmpPath boolean is used to determine if @tmpPath holds
> an allocated memory or is a pointer to a constant string and
> therefore if it needs to be freed or not when returning from the
> function. Well, we can unify the way we set @tmpPath so
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> There are several variables which could be automatically freed
> upon return from the function. I'm not changing @tmpPaths (which
> is a string list) because it is going to be removed in next
> commit.
>
> Signed-off-by: Michal Privoznik
> ---
>
I already try to make sure all bitmaps patches have been reviewed by both
Red Hat and Virtuozzo anyway, so this formalizes the arrangement.
Fam meanwhile is no longer as active, so I am removing him as a co-maintainer
simply to reflect the current practice.
Signed-off-by: John Snow
Reviewed-by:
From: Vladimir Sementsov-Ogievskiy
- Correct check for write access to file child, and in correct place
(only if we want to write).
- Support reopen rw -> rw (which will be used in following commit),
for example, !bdrv_dirty_bitmap_readonly() is not a corruption if
bitmap is marked IN_USE
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20190927122355.7344-8-vsement...@virtuozzo.com
[Maintainer edit: removed 260 from auto group per Peter Maydell. --js]
Signed-off-by: John Snow
---
tests/qemu-iotests/260 | 89
From: Vladimir Sementsov-Ogievskiy
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all
readonly. But the latter don't work, as
qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing.
It's OK for inactivation but bad idea for reopen-ro. And this leads to
the
From: Vladimir Sementsov-Ogievskiy
The only reason I can imagine for this strange code at the very-end of
bdrv_reopen_commit is the fact that bs->read_only updated after
calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same
time, prior to previous commit, qcow2_reopen_bitmaps_rw
This parameter has been deprecated since 2.12.0 and is eligible for
removal. Remove this parameter as it is actually completely ignored;
let's not give false hope.
Signed-off-by: John Snow
Reviewed-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Message-id:
From: Vladimir Sementsov-Ogievskiy
The function is unused, drop it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20190927122355.7344-6-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
block/qcow2.h| 2 --
block/qcow2-bitmap.c | 15
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> In near future, the decision what to do with /dev/vfio/vfio with
> respect to domain namespace and CGroup is going to be moved out
> of qemuDomainGetHostdevPath() because there will be some other
> types of devices than hostdevs that need access to
On 9/26/19 12:12 PM, Michal Privoznik wrote:
> There are three cases where vir*DeviceGetPath() returns a const
> string. In these cases, the string is initialized in
> corresponding vir*DeviceNew() calls which fail if string couldn't
> be allocated. There's no point in checking the second time if
95 matches
Mail list logo
