Ping.
It seems no one handle this patch.
> -Original Message-
> From: Pankaj Gupta [mailto:pankaj.gupta.li...@gmail.com]
> Sent: Wednesday, December 09, 2020 10:21 PM
> To: tuguoyi (Cloud)
> Cc: Juan Quintela ; Dr. David Alan Gilbert
> ; vsement...@virtuozzo
The snapshot in each bs is deleted at the beginning, so there is no need
to find the snapshot again.
Signed-off-by: Tuguoyi
---
migration/savevm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/migration/savevm.c b/migration/savevm.c
index 5f937a2..601b514 100644
bdrv_all_create_snapshot() can fails with some snapshots created,
so it's better to delete those snapshots before returns to the caller
Signed-off-by: Tuguoyi
---
migration/savevm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/migration/savevm.c b/migration/savevm.c
index 60
These two patches just clear dead code and delete stale snapshots
in case of error in save_snapshot()
Tuguoyi (2):
savevm: Remove dead code in save_snapshot()
savevm: Delete snapshots just created in case of error
migration/savevm.c | 11 +++
1 file changed, 3 insertions(+), 8
v_inactivate_all(), and during the second migration the
bdrv_inactivate_recurse assert that the bs->open_flags is already
BDRV_O_INACTIVE enabled which cause crash.
As Vladimir suggested, this patch makes migrate_prepare check the state of vm
and
return error if it is in RUN_STATE_POSTMIGRATE stat
On December 07, 2020 6:06 PM Vladimir Sementsov-Ogievskiy wrote:
> 07.12.2020 10:44, Tuguoyi wrote:
> > The following steps will cause qemu assertion failure:
> > - pause vm by executing 'virsh suspend'
> > - create external snapshot of memory and disk us
POSTMIGRATE state.
Signed-off-by: Tuguoyi
---
migration/migration.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/migration/migration.c b/migration/migration.c
index 87a9b59..4091678 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -3622,6 +3622,13 @@ void migrate_fd
> -Original Message-
> From: Vladimir Sementsov-Ogievskiy [mailto:vsement...@virtuozzo.com]
> Sent: Saturday, November 28, 2020 4:48 PM
> To: tuguoyi (Cloud) ; Kevin Wolf ;
> Max Reitz ; qemu-bl...@nongnu.org
> Cc: qemu-devel@nongnu.org; wangyong (Cloud)
> Subje
crash.
>
> This patch just make the bdrv_inactivate_all() to don't inactivate the bs if
> it is
> already inactive
>
> Signed-off-by: Tuguoyi
> ---
> block.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/block.c b/bloc
the
bdrv_inactivate_recurse assert that the bs->open_flags is already
BDRV_O_INACTIVE
enabled which cause crash.
This patch just make the bdrv_inactivate_all() to don't inactivate the bs if it
is
already inactive
Signed-off-by: Tuguoyi
---
block.c | 7 ++-
1 file changed, 6 inser
On Wed, 2019-07-03 at 10:13 -0500, Eric Blake wrote:
> On 11/5/20 2:31 AM, Max Reitz wrote:
> > On 05.11.20 06:40, Tuguoyi wrote:
> >> As BDRV_SECTOR_SIZE is of type uint64_t, the expression will
> >> automatically convert the @ret to uint64_t. When an error code
> &g
Sorry, please ignore this patch, it's not a right fix
--
Best regards,
Guoyi
> -Original Message-
> From: tuguoyi (Cloud)
> Sent: Thursday, November 05, 2020 11:11 AM
> To: 'Kevin Wolf' ; 'Max Reitz' ;
> 'qemu-bl...@nongnu.org'
>
As BDRV_SECTOR_SIZE is of type uint64_t, the expression will
automatically convert the @ret to uint64_t. When an error code
returned from bdrv_nb_sectors(), the promoted @ret will be a very
large number, as a result the -EFBIG will be returned which is not the
real error code.
Signed-off-by: Guoyi
The return code from bdrv_nb_sectors() should be checked before doing
the following sanity check.
Signed-off-by: Guoyi Tu
---
block.c | 4
1 file changed, 4 insertions(+)
diff --git a/block.c b/block.c
index 430edf7..19ebbc0 100644
--- a/block.c
+++ b/block.c
@@ -5082,6 +5082,10 @@ int64_
@sn_opts is initialized at the beginning, so it should be deleted
after jumping to the lable 'fail_getopt'
Signed-off-by: Guoyi Tu
---
qemu-img.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-img.c b/qemu-img.c
index 2103507..229cdf9 100644
--- a/qemu-img.c
+++ b/qemu-
When calculating the offset, the result of left shift operation will be promoted
to type int64 automatically because the left operand of + operator is uint64_t.
but the result after integer promotion may be produce an error value for us and
trigger the following asserting error.
For example, consi
OK, I got it, it will be released in aio_ctx_finalize().
Please ignore this mail.
> -Original Message-
> From: tuguoyi (Cloud)
> Sent: Sunday, January 19, 2020 4:15 PM
> To: 'Stefan Hajnoczi' ; 'Fam Zheng'
> ; 'qemu-bl...@nongnu.org'
>
In aio_context_new(), the @notifier variable will be initialized, but it
don't get cleaned up in aio_context_unref() when reference count reaches
to 0, it will cause file descriptor leak.
--
Best regards,
Guoyi
The local_err check outside of the if block was necessary
when it was introduced in commit d1258dd0c87 because it needed to be
executed even if qcow2_load_autoloading_dirty_bitmaps() returned false.
After some modifications that all required the error check to remain
where it is, commit 9c98f145df
On 18.12.2019 17:33 Kevin Wolf wrote:
>
> Am 18.12.2019 um 03:26 hat Tuguoyi geschrieben:
> >
> > Signed-off-by: Guoyi Tu
>
> Empty commit messages are rarely acceptable. You should explain here why
> you are making the change and why it's correct (for example
Signed-off-by: Guoyi Tu
---
block/qcow2.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 7c18721..ce3db29 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1705,14 +1705,14 @@ static int coroutine_fn qcow2_do_open(BlockDriverSt
On 01.11.2019 18:09, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 12:34, Tuguoyi wrote:
> > On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote:
> >> 01.11.2019 10:37, Tuguoyi wrote:
> >>> There are two issues in In check_constraints_on_bitmap(),
> >>&
On 01.11.2019 17:25 Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 10:37, Tuguoyi wrote:
> > There are two issues in In check_constraints_on_bitmap(),
> > 1) The sanity check on the granularity will cause uint64_t integer
> > left-shift overflow when cluster_size is 2M a
There are two issues in In check_constraints_on_bitmap(),
1) The sanity check on the granularity will cause uint64_t
integer left-shift overflow when cluster_size is 2M and the
granularity is BIGGER than 32K.
2) The way to calculate image size that the maximum bitmap
supported can map to is a bit i
There are two issues in In check_constraints_on_bitmap(),
1) The sanity check on the granularity will cause uint64_t
integer left-shift overflow when cluster_size is 2M and the
granularity is BIGGER than 32K.
2) The way to calculate image size that the maximum bitmap
supported can map to is a bit i
On 29.10.2019 19:57 Vladimir Sementsov-Ogievskiy wrote:
> 29.10.2019 14:14, Max Reitz wrote:
> > On 28.10.19 07:33, Tuguoyi wrote:
> >> In check_constraints_on_bitmap(), the sanity check on the granularity
> >> will cause uint64_t integer left-shift overflow when clus
In check_constraints_on_bitmap(), the sanity check on the
granularity will cause uint64_t integer left-shift overflow
when cluster_size is 2M and the granularity is BIGGER than
32K. As a result, for a qcow2 disk with cluster_size set to
2M, we could not even create a dirty bitmap with default
granu
In check_constraints_on_bitmap(), the sanity check on the
granularity will cause uint64_t integer left-shift overflow
when cluster_size is 2M and the granularity is bigger than
32K which is even smaller than the default value for a qcow2
disk with cluster_size set to 64k or bigger. This patch fix
t
28 matches
Mail list logo