ilmap | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >
> diff --git a/.mailmap b/.mailmap > index 3816e4effe..3fbf3902a3 100644 > ---
a/.mailmap > +++ b/.mailmap > @@ -151,7 +151,8 @@ Xiaoqiang Zhao
> Xinhua Cao > Xiong Zhang
> Yin Yin > -yuchenlin
>
Hi, Samuel
This patch has been viewed by Daniel.
Please see
https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html
However, Daniel has not sent a PR which includes this patch.
Thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is su
I have sent a patch about this problem.
Please see https://lists.nongnu.org/archive/html/qemu-
devel/2019-11/msg03924.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1849644
Title:
QEMU VNC web
; vhost-user-blk devices. > > Suggested-by: Phillippe
Mathieu-Daude > Signed-off-by: Raphael Norwitz
Reviewed-by: yuchenlin
Thanks. > > > --- > hw/block/vhost-user-blk.c | 2 +- > 1 file changed, 1
insertion(+), 1 deletion(-) > > diff --git a/hw/block/vhost-user-blk.c
I re-test the dmg img with QEMU 4.0 again, and it works.
In my opinion, the bug can be closed as "Fix released".
Thanks.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1809304
Title:
qemu-img conv
checked in the section Grain Table and Grain in
page No.8 of the spec.
Reviewed-by: yuchenlin
On 2019-03-25 12:26, Jason Wang wrote:
On 2019/3/21 上午9:35, yuchenlin wrote:
Ping?
On 2019-03-13 14:56, yuchen...@synology.com wrote:
From: yuchenlin
Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32
guest.
In
Ping?
On 2019-03-13 14:56, yuchen...@synology.com wrote:
From: yuchenlin
Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will
From: yuchenlin
Due to too early RCT0 interrput, win10x32 may hang on booting.
This problem can be reproduced by doing power cycle on win10x32 guest.
In our environment, we have 10 win10x32 and stress power cycle.
The problem will happen about 20 rounds.
Below shows some log with comment:
The
From: yuchenlin
In vmdk_co_create_opts, when it finds hw_version is undefined, it will
set it to 4, which misleading the compat6 and hwversion in
vmdk_co_do_create. Simply set hw_version to NULL after free, let
the logic in vmdk_co_do_create to decide the value of hw_version.
This bug can be
Recently, some bugs in dmg file have been fixed. To prevent reading dmg
is broken someday in the future, add a simple test which ensures the
conversion from dmg to raw should not hang or face any I/O error.
Signed-off-by: yuchenlin
---
tests/qemu-iotests/236| 53
is patch, we treat zero chunk the same as ignore chunk, it will
directly write zero and avoid some sector may not find the table.
After this patch:
[---The expanded file]
[---bzip table ---][--zeros--][---zlib---]
Signed-off-by: yuchenlin
Reviewed-by: Julio Faracco
Reviewed-b
Signed-off-by: yuchenlin
Reviewed-by: Julio Faracco
Reviewed-by: Stefan Hajnoczi
---
block/dmg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/dmg.c b/block/dmg.c
index 65a0140487..9758482131 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -267,7 +267,7 @@ static
add Reviewed tag in patch 2 and 3
v1 -> v2:
* fix typos in patch 1
* add patch 2 and patch 3
yuchenlin (3):
dmg: fix binary search
dmg: use enumeration type instead of hard coding number
dmg: don't skip zero chunk
block/dmg.c | 29 +++--
1 file changed, 19
There is a possible hang in original binary search implementation. That is
if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
The chunk1 will be still 4, and so on.
Signed-off-by: yuchenlin
---
block/dmg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a
-by: Julio Faracco
Reviewed-by: yuchenlin
---
block/dmg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/dmg.c b/block/dmg.c
index 50e91aef6d..2c806e3389 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -54,7 +54,7 @@ enum {
UDBZ,
ULFO,
UDCM = 0x7ffe
Because of lacking zero chunk table, reading zero sector will return EIO.
I have submitted a series to fix this problem.
Please refer to this series: http://lists.nongnu.org/archive/html/qemu-
devel/2018-12/msg05637.html
Thanks,
Yu-Chen Lin
--
You received this bug notification because you are
There is a possible hang in original binary search implementation. That is
if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
The chunk1 will be still 4, and so on.
Signed-off-by: yuchenlin
---
block/dmg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block
Signed-off-by: yuchenlin
---
block/dmg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/dmg.c b/block/dmg.c
index 0e05702f5d..6b0a057bf8 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -267,7 +267,7 @@ static int dmg_read_mish_block(BDRVDMGState *s,
DmgHeaderState
is patch, we treat zero chunk the same as ignore chunk, it will
directly write zero and avoid some sector may not find the table.
After this patch:
[---The expanded file]
[---bzip table ---][--zeros--][---zlib---]
Signed-off-by: yuchenlin
---
block/dmg.c | 19 -
h 3
yuchenlin (3):
dmg: fix binary search
dmg: use enumeration type instead of hard coding number
dmg: don't skip zero chunk
block/dmg.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
--
2.17.1
I have submitted a patch to prevent hanging in binary search.
See:
http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg05453.html?fbclid=IwAR0ObsaZ4kVMVv6MWIdq0ZCAN5tGhDsd9GmFv8_v7HBTl94Cu5EkRZ3z4n4
Thanks,
Yu-Chen Lin
--
You received this bug notification because you are a member of qem
There is a possible hang in original binary searsh implemtation. That is
if chunk1 = 4, chunk2 = 5, chunk3 = 4, and we go else case.
The chunk1 will be still 4, and so on.
Signed-off-by: yuchenlin
---
block/dmg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block
On 2018-10-29 17:44, Gerd Hoffmann wrote:
On Mon, Oct 22, 2018 at 04:00:53PM +0800, yuchen...@synology.com wrote:
From: yuchenlin
Signed-off-by: yuchenlin
---
hw/display/vga_int.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6e4fa48a79
From: yuchenlin
Signed-off-by: yuchenlin
---
hw/display/vga_int.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6e4fa48a79..55c418eab5 100644
--- a/hw/display/vga_int.h
+++ b/hw/display/vga_int.h
@@ -166,7 +166,6 @@ MemoryRegion
Ping?
On 2018-10-12 17:07, yuchen...@synology.com wrote:
From: yuchenlin
There are 3 virtqueues (ctrl, event and cmd) for virtio scsi device,
but seabios will only set the physical address for the 3rd one (cmd).
Then in vhost_virtqueue_start(), virtio_queue_get_desc_addr()
will be 0 for ctrl
From: yuchenlin
There are 3 virtqueues (ctrl, event and cmd) for virtio scsi device,
but seabios will only set the physical address for the 3rd one (cmd).
Then in vhost_virtqueue_start(), virtio_queue_get_desc_addr()
will be 0 for ctrl and event vq.
In this case, ctrl and event vq are not
On 2018-10-08 10:38, Fam Zheng wrote:
On Fri, 10/05 10:00, yuchenlin wrote:
Ping?
Hi,
This was merged as 51b3c6b73acae1e3fd3c7d441fc86dd17356695f.
Fam
Hi,
Thank you for your information.
yuchenlin
On 2018-09-13 16:34, Fam Zheng wrote:
> On Thu, 09/13 16:29, yuchen...@synology.
Ping?
On 2018-09-13 16:34, Fam Zheng wrote:
On Thu, 09/13 16:29, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
There are three
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
There are three reasons to do it. First, if vmdk doesn't align at
the sector boundary, there may be many unde
On 2018-09-13 10:54, Fam Zheng wrote:
On Thu, 09/13 10:31, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
The code looks good to me
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
---
v1 -> v2:
* Add more detail comment.
* Add QEMU_ALIGN_UP to show the intention m
On 2018-09-12 19:54, Fam Zheng wrote:
On Tue, 08/28 11:17, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
Fam Zheng 於 2018-09-12 17:34 寫道：
> On Tue, 08/28 11:17, yuchen...@synology.com wrote: > From: yuchenlin
> > > There is a rare case which the size of last
> compressed cluster > is larger than the cluster size, which will cause the
> file is > not aligned at t
Ping!
yuchen...@synology.com 於 2018-08-28 11:18 寫道：
> From: yuchenlin There is a rare case which the size
> of last compressed cluster is larger than the cluster size, which will cause
> the file is not aligned at the sector boundary. Signed-off-by: yuchenlin
> --- block
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
---
block/vmdk.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a
plies, vdi_co_pwritev shows the code parts for vdi write support.
I appreciated your time and effort for reviews.
Regards,
yuchenlin
Stefan Weil 於 2018-07-30 15:13 寫道：
> Am 30.07.2018 um 04:46 schrieb yuchen...@synology.com: > From: yuchenlin
> > > This series refine some cod
From: yuchenlin
The CONFIG_VDI_WRITE is here when the first time vdi is added.
But there is no reason to leave an always on and cannot configure option
in the code-side.
Signed-off-by: yuchenlin
---
block/vdi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
From: yuchenlin
This series refine some code in vdi.c, includes:
* Remvoe CONFIG_VDI_WRITE because there is no reason to leave an always on
and cannot configure option in the code-side.
* decouple if else if chain to get more readability.
Thanks,
yuchenlin
yuchenlin (2):
vdi: remove
From: yuchenlin
When the condition of each if or else if is true,
the code flow will goto fail. Which means we can decouple
if else if chain to get some readability.
Signed-off-by: yuchenlin
---
block/vdi.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a
useless offset
in grain table. We should return
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a
useless offset
in grain table. We should return
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To prevent offset overflow and record a useless offset
in grain table. We should return un-support here.
Signed
43 matches
Mail list logo
