On 07/24/2017 02:07 PM, Lluís Vilanova wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> 21.07.2017 20:04, Lluís Vilanova wrote:
>>> Vladimir Sementsov-Ogievskiy writes:
>>>
Current trace system have a drawback: parameters of trace functions
are calculated even if corresponding
On 07/14/2017 01:20 PM, Paolo Bonzini wrote:
> On 14/07/2017 11:29, Denis V. Lunev wrote:
>> On 07/06/2017 03:08 PM, Anton Nefedov wrote:
>>> Changed in v6:
>>> - patch 3: chr_lock mutex removed (as discussed, thread safety can be
>>> left to
>>>
On 07/06/2017 03:08 PM, Anton Nefedov wrote:
> Changed in v6:
> - patch 3: chr_lock mutex removed (as discussed, thread safety can be left
> to
> the front-ends, and the front-ends currently supported are good as is).
> - patch 5 now includes related changes for serial and virtio-serial
We've had a shadowed 'ret' variable, which risks returning the wrong
value, introduced in commit b9c64947.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
Reviewed-by: Fam Zheng <f...@redhat.com>
CC: Stefan Hajnoczi <stefa...@redhat.com>
CC: Kevin Wolf <kw...@redhat.com
On 07/10/2017 04:51 PM, Eric Blake wrote:
> On 07/10/2017 03:35 AM, Denis V. Lunev wrote:
>> Signed-off-by: Denis V. Lunev <d...@openvz.org>
>> CC: Stefan Hajnoczi <stefa...@redhat.com> (supporter:Block I/O path)
>> CC: Fam Zheng <f...@redhat.com> (support
On 07/10/2017 04:59 PM, Kevin Wolf wrote:
> Am 10.07.2017 um 10:35 hat Denis V. Lunev geschrieben:
>> Signed-off-by: Denis V. Lunev <d...@openvz.org>
>> CC: Stefan Hajnoczi <stefa...@redhat.com> (supporter:Block I/O path)
>> CC: Fam Zheng <f...@r
On 07/10/2017 11:56 AM, Fam Zheng wrote:
> On Mon, 07/10 11:35, Denis V. Lunev wrote:
>> Signed-off-by: Denis V. Lunev <d...@openvz.org>
>> CC: Stefan Hajnoczi <stefa...@redhat.com> (supporter:Block I/O path)
>> CC: Fam Zheng <f...@redhat.com> (supporter
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com> (supporter:Block I/O path)
CC: Fam Zheng <f...@redhat.com> (supporter:Block I/O path)
---
block/io.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/block/io.c b/block/io.c
index ed31
On 07/06/2017 08:53 PM, John Snow wrote:
>
> On 07/06/2017 04:05 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 06.07.2017 00:46, John Snow wrote:
>>> On 07/05/2017 05:24 AM, Vladimir Sementsov-Ogievskiy wrote:
16.02.2017 16:04, Fam Zheng wrote:
>> +dbms->node_name =
; +static int coroutine_fn
> +parallels_create(const char *filename, QemuOpts *opts, Error **errp)
> {
> int64_t total_size, cl_size;
> uint8_t tmp[BDRV_SECTOR_SIZE];
Reviewed-by: Denis V. Lunev <d...@openvz.org>
On 06/27/2017 03:34 PM, Peter Lieven wrote:
> this patch adds a new compression_algorithm option when creating qcow2 images.
> The current default for the compresison algorithm is zlib and zlib will be
> used when this option is omitted (like before).
>
> If the option is specified e.g. with:
>
>
On 06/27/2017 04:27 PM, Peter Lieven wrote:
> Am 27.06.2017 um 15:20 schrieb Daniel P. Berrange:
>> On Tue, Jun 27, 2017 at 02:34:07PM +0200, Peter Lieven wrote:
>>> this patch adds a new compression_algorithm option when creating
>>> qcow2 images.
>>> The current default for the compresison
On 06/26/2017 11:54 PM, Peter Lieven wrote:
>
>> Am 26.06.2017 um 22:30 schrieb Denis V. Lunev <d...@openvz.org>:
>>
>>> On 06/26/2017 11:28 AM, Kevin Wolf wrote:
>>> [ Cc: qemu-devel; don't post to qemu-block only! ]
>>>
>>> Am
On 06/26/2017 11:28 AM, Kevin Wolf wrote:
> [ Cc: qemu-devel; don't post to qemu-block only! ]
>
> Am 26.06.2017 um 09:57 hat Peter Lieven geschrieben:
>> Hi,
>>
>> I am currently working on optimizing speed for compressed QCOW2
>> images. We use them for templates and would also like to use them
On 06/26/2017 01:16 PM, Laszlo Ersek wrote:
> On 06/26/17 11:33, Denis V. Lunev wrote:
>> On 06/26/2017 12:20 PM, Peter Lieven wrote:
>>> Am 26.06.2017 um 10:28 schrieb Kevin Wolf:
>>>> [ Cc: qemu-devel; don't post to qemu-block only! ]
>>>>
>>>&g
On 06/26/2017 01:04 PM, Daniel P. Berrange wrote:
> On Mon, Jun 26, 2017 at 11:20:33AM +0200, Peter Lieven wrote:
>> Am 26.06.2017 um 10:28 schrieb Kevin Wolf:
>>> [ Cc: qemu-devel; don't post to qemu-block only! ]
>>>
>>> Am 26.06.2017 um 09:57 hat Peter Lieven geschrieben:
Hi,
I
On 06/26/2017 12:20 PM, Peter Lieven wrote:
>
> Am 26.06.2017 um 10:28 schrieb Kevin Wolf:
>> [ Cc: qemu-devel; don't post to qemu-block only! ]
>>
>> Am 26.06.2017 um 09:57 hat Peter Lieven geschrieben:
>>> Hi,
>>>
>>> I am currently working on optimizing speed for compressed QCOW2
>>> images. We
On 06/01/2017 12:12 PM, Kevin Wolf wrote:
> Am 31.05.2017 um 17:03 hat Eric Blake geschrieben:
>> On 05/31/2017 09:43 AM, Pavel Butsykin wrote:
>>> This patch adds the reduction of the image file for qcow2. As a result, this
>>> allows us to reduce the virtual image size and free up space on the
On 05/26/2017 11:11 AM, Kevin Wolf wrote:
>
> No. This is what you bypass:
some analysis for the record.
> * All sanity checks that the block layer does
>
> * bdrv_inc/dec_in_flight(), which is required for drain to work
> correctly. Not doing this will cause crashes.
Should not be a problem.
On 05/26/2017 11:11 AM, Kevin Wolf wrote:
> Am 19.05.2017 um 11:34 hat Anton Nefedov geschrieben:
>> From: "Denis V. Lunev" <d...@openvz.org>
>>
>> Currently each single write operation can result in 3 write operations
>> if guest offsets are
On 05/24/2017 05:07 PM, Denis Plotnikov wrote:
> Do an update of system_time_msr address every time before reading
> the value of tsc_timestamp from guest's kvmclock page.
>
> It should be done in a forcible manner because there is a situation
> when system_time_msr has been set by kvm but qemu
On 05/23/2017 05:35 PM, Eric Blake wrote:
> On 05/19/2017 04:34 AM, Anton Nefedov wrote:
>> This pull request is to address a few performance problems of qcow2 format:
>>
>> 1. non cluster-aligned write requests (to unallocated clusters) explicitly
>> pad data with zeroes if there is no
On 05/22/2017 04:02 PM, Eric Blake wrote:
> On 05/22/2017 06:56 AM, Denis V. Lunev wrote:
>>>
>>> As it is, your patch doesn't apply to master. And even if it did, your
>>> patch breaks semantics - we CANNOT discard clusters that must read back
>>> as zeroe
On 05/22/2017 10:24 PM, Eric Blake wrote:
> On 05/19/2017 04:34 AM, Anton Nefedov wrote:
>> If COW area of the newly allocated cluster is zeroes, there is no reason
>> to write zero sectors in perform_cow() again now as whole clusters are
>> zeroed out in single chunks by handle_alloc_space().
>
On 05/22/2017 10:00 PM, Eric Blake wrote:
> On 05/19/2017 04:34 AM, Anton Nefedov wrote:
>> From: "Denis V. Lunev" <d...@openvz.org>
>>
>> Currently each single write operation can result in 3 write operations
>> if guest offsets are not cluster alig
On 05/22/2017 02:37 PM, Eric Blake wrote:
> On 05/21/2017 09:21 AM, Denis V. Lunev wrote:
>> qemu-img create -f qcow2 1.img 64G
>> qemu-io -c "write -P 0x32 0 64k" 1.img
>> results in
>> 324 -rw-r--r-- 1 den den 393216 May 21 16:48 1.img
>> Subseq
ites will come in small pieces.
This is not a very big deal if we have filesystem with PUCH_HOLE support,
but without this feature the cluster is actually leaked forever.
The patch replaces zero_single_l2 with discard_single_l2 and removes
now unused zero_single_l2 to fix the situation.
Signed-off-by: Denis V. Lun
On 05/18/2017 05:54 PM, Kevin Wolf wrote:
> Am 18.05.2017 um 14:22 hat Denis V. Lunev geschrieben:
>> On 05/18/2017 03:10 PM, Kevin Wolf wrote:
>>> Am 18.05.2017 um 13:04 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>>> 18.05.2017 13:25, Kevin Wolf wrote:
&g
On 05/18/2017 03:10 PM, Kevin Wolf wrote:
> Am 18.05.2017 um 13:04 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 18.05.2017 13:25, Kevin Wolf wrote:
>>> Am 18.05.2017 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
Shows, how much data qcow2 allocates in underlying file. This should
On 05/18/2017 01:25 PM, Kevin Wolf wrote:
> Am 18.05.2017 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> Shows, how much data qcow2 allocates in underlying file. This should
>> be helpful on non-sparse file systems, when qemu-img info "disk size"
>> doesn't provide this information.
>>
On 05/11/2017 08:43 PM, John Snow wrote:
>
> On 05/11/2017 02:35 PM, Stefan Hajnoczi wrote:
>> Daniel's proposed patch isn't large or invasive. The QMP interface is
>> consistent with the backup block job's sync=bitmap mode, it's a logical
>> extension.
>>
>> If the concerns about the bitmap
On 05/11/2017 04:16 PM, Daniel Kučera wrote:
>
> 2017-05-10 17:05 GMT+02:00 Denis V. Lunev <d...@openvz.org
> <mailto:d...@openvz.org>>:
>
> On 05/10/2017 05:00 PM, Stefan Hajnoczi wrote:
> > On Wed, May 10, 2017 at 03:25:31PM +0200, Denis V. Lunev wrote
On 05/10/2017 05:54 PM, Markus Armbruster wrote:
> "Denis V. Lunev" <d...@openvz.org> writes:
>
>> On 05/03/2017 02:29 PM, Markus Armbruster wrote:
>>> "Denis V. Lunev" <d...@openvz.org> writes:
>>>
>>>> On 05/02/2017 07
On 05/10/2017 05:00 PM, Stefan Hajnoczi wrote:
> On Wed, May 10, 2017 at 03:25:31PM +0200, Denis V. Lunev wrote:
>> On 05/09/2017 06:52 PM, Stefan Hajnoczi wrote:
>>> On Mon, May 08, 2017 at 05:07:18PM -0400, John Snow wrote:
>>>> On 05/08/2017 05:02 PM, Denis V. Lu
On 05/09/2017 06:52 PM, Stefan Hajnoczi wrote:
> On Mon, May 08, 2017 at 05:07:18PM -0400, John Snow wrote:
>>
>> On 05/08/2017 05:02 PM, Denis V. Lunev wrote:
>>> On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote:
>>>> On Thu, May 04, 2017 at 12:54:40PM +0200,
On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote:
> On Thu, May 04, 2017 at 12:54:40PM +0200, Daniel Kucera wrote:
>
> Seems like a logical extension along the same lines as the backup block
> job's dirty bitmap sync mode.
>
>> parameter bitmap chooses existing dirtymap instead of newly created
>> in
On 05/03/2017 02:29 PM, Markus Armbruster wrote:
> "Denis V. Lunev" <d...@openvz.org> writes:
>
>> On 05/02/2017 07:48 PM, Daniel P. Berrange wrote:
>>> On Tue, May 02, 2017 at 05:36:30PM +0100, Dr. David Alan Gilbert wrote:
>>>> * Markus Armbruster
On 05/03/2017 02:35 PM, Daniel P. Berrange wrote:
> On Wed, May 03, 2017 at 01:29:57PM +0200, Markus Armbruster wrote:
>> "Denis V. Lunev" <d...@openvz.org> writes:
>>
>>> On 05/02/2017 07:48 PM, Daniel P. Berrange wrote:
>>>> On Tue, May 02, 20
On 05/02/2017 07:48 PM, Daniel P. Berrange wrote:
> On Tue, May 02, 2017 at 05:36:30PM +0100, Dr. David Alan Gilbert wrote:
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> "Denis V. Lunev" <d...@openvz.org> writes:
>>>
>>>> On 05/02
On 05/02/2017 05:34 PM, Eric Blake wrote:
> On 05/02/2017 08:47 AM, Denis V. Lunev wrote:
>> Right now QMP and HMP monitors read 1 byte at a time from the socket, which
>> is very inefficient. With 100+ VMs on the host this easily reasults in
> s/reasults/results/
>
>>
On 05/02/2017 05:43 PM, Markus Armbruster wrote:
> "Denis V. Lunev" <d...@openvz.org> writes:
>
>> Right now QMP and HMP monitors read 1 byte at a time from the socket, which
>> is very inefficient. With 100+ VMs on the host this easily reasults in
>> a
on the channel level. Fortunately, monitor protocol is
synchronous right now thus we should not face side effects in reality.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Markus Armbruster <arm...@redhat.com>
CC: "Dr. David Alan Gilbert" <dgilb...@redhat
On 04/28/2017 09:31 PM, Eric Blake wrote:
> On 04/28/2017 11:17 AM, Denis V. Lunev wrote:
>> Hello, All!
>>
>> Recently we have experienced problems with very slow
>> bdrv_get_block_status call, which is massive called f.e.
>> from mirror_run().
>>
>>
On 04/28/2017 09:31 PM, Eric Blake wrote:
> On 04/28/2017 11:17 AM, Denis V. Lunev wrote:
>> Hello, All!
>>
>> Recently we have experienced problems with very slow
>> bdrv_get_block_status call, which is massive called f.e.
>> from mirror_run().
>>
>>
On 04/28/2017 10:35 PM, Denis V. Lunev wrote:
> On 04/28/2017 09:31 PM, Eric Blake wrote:
>> On 04/28/2017 11:17 AM, Denis V. Lunev wrote:
>>> Hello, All!
>>>
>>> Recently we have experienced problems with very slow
>>> bdrv_get_block_status call, whi
Hello, All!
Recently we have experienced problems with very slow
bdrv_get_block_status call, which is massive called f.e.
from mirror_run().
The problem was narrowed down to slow lseek64() system
call, which can take 1-2-3 seconds.
root@s158 ~]# strace -f -p 77048 -T -e lseek
Process 77048
to put this into stable. The problem is here
from the very beginning.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
CC: Fam Zheng <f...@redhat.com>
---
block/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block
On 04/18/2017 02:22 PM, Kevin Wolf wrote:
> Am 14.04.2017 um 06:17 hat Denis V. Lunev geschrieben:
>> [skipped...]
>>
>>> Hi Denis,
>>>
>>> I've read this entire thread now and I really like Berto's summary which
>>> I think i
On 04/18/2017 02:52 PM, Alberto Garcia wrote:
> On Thu 13 Apr 2017 05:17:21 PM CEST, Denis V. Lunev wrote:
>> On 04/13/2017 06:04 PM, Alberto Garcia wrote:
>>> On Thu 13 Apr 2017 03:30:43 PM CEST, Denis V. Lunev wrote:
>>>> Yes, block size should be incre
sector-based functions; but that's okay
> because request_alignment is 512 as a result of those functions.
>
> Signed-off-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Denis V. Lunev <d...@openvz.org>
> ---
> block/parallels.c | 15 +--
> 1 file changed, 9 in
commit 2d9187bc65.
Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Peter Lieven <p...@kamp.de>
CC: Kevin Wolf <kw...@redhat.com>
CC: Max Reitz <mre...@redhat.com>
---
qemu-img.c | 2 +-
1 file changed, 1 ins
[skipped...]
> Hi Denis,
>
> I've read this entire thread now and I really like Berto's summary which
> I think is one of the best recaps of existing qcow2 problems and this
> discussion so far.
>
> I understand your opinion that we should focus on compatible changes
> before incompatible ones,
On 04/13/2017 04:05 PM, Kevin Wolf wrote:
> Am 13.04.2017 um 14:44 hat Denis V. Lunev geschrieben:
>> On 04/13/2017 02:58 PM, Alberto Garcia wrote:
>>> On Wed 12 Apr 2017 06:54:50 PM CEST, Denis V. Lunev wrote:
>>>> My opinion about this approach is very
On 04/13/2017 12:44 PM, Kevin Wolf wrote:
> Am 12.04.2017 um 21:02 hat Denis V. Lunev geschrieben:
>> On 04/12/2017 09:20 PM, Eric Blake wrote:
>>> On 04/12/2017 12:55 PM, Denis V. Lunev wrote:
>>>> Let me rephrase a bit.
>>>>
>>>> Th
On 04/13/2017 04:21 PM, Alberto Garcia wrote:
> On Thu 13 Apr 2017 02:44:51 PM CEST, Denis V. Lunev wrote:
>>>> 1) current L2 cache management seems very wrong to me. Each cache
>>>> miss means that we have to read entire L2 cache block. This means
>>>>
On 04/13/2017 06:04 PM, Alberto Garcia wrote:
> On Thu 13 Apr 2017 03:30:43 PM CEST, Denis V. Lunev wrote:
>> Yes, block size should be increased. I perfectly in agreement with
>> your. But I think that we could do that by plain increase of the
>> cluster size without an
On 04/13/2017 04:51 PM, Kevin Wolf wrote:
> Am 13.04.2017 um 15:21 hat Alberto Garcia geschrieben:
>> This invariant is already broken by the very design of the qcow2 format,
>> subclusters don't really add anything new there. For any given cluster
>> size you can write 4k in every odd cluster,
On 04/13/2017 04:36 PM, Alberto Garcia wrote:
> On Thu 13 Apr 2017 03:09:53 PM CEST, Denis V. Lunev wrote:
>>>> For nowadays SSD we are facing problems somewhere else. Right now I
>>>> can achieve only 100k IOPSes on SSD capable of 350-550k. 1 Mb block
>>>&g
On 04/13/2017 02:58 PM, Alberto Garcia wrote:
> On Wed 12 Apr 2017 06:54:50 PM CEST, Denis V. Lunev wrote:
>> My opinion about this approach is very negative as the problem could
>> be (partially) solved in a much better way.
> Hmm... it seems to me that (some of) the problems
On 04/12/2017 09:20 PM, Eric Blake wrote:
> On 04/12/2017 12:55 PM, Denis V. Lunev wrote:
>> Let me rephrase a bit.
>>
>> The proposal is looking very close to the following case:
>> - raw sparse file
>>
>> In this case all writes are very-very-very fast
On 04/12/2017 05:05 PM, Mihail Abakumov wrote:
> Hello.
>
> We made the debugger module WinDbg (like GDB) for QEMU. This is the
> replacement of the remote stub in Windows kernel. Used for remote
> Windows kernel debugging without debugging mode.
>
> The latest build and instructions for the
On 04/06/2017 06:01 PM, Alberto Garcia wrote:
> Hi all,
>
> over the past couple of months I discussed with some of you the
> possibility to extend the qcow2 format in order to improve its
> performance and reduce its memory requirements (particularly with very
> large images).
>
> After some
On 04/06/2017 06:01 PM, Alberto Garcia wrote:
> Hi all,
>
> over the past couple of months I discussed with some of you the
> possibility to extend the qcow2 format in order to improve its
> performance and reduce its memory requirements (particularly with very
> large images).
>
> After some
On 04/06/2017 06:14 PM, Stefan Hajnoczi wrote:
> On Wed, Apr 05, 2017 at 06:12:05PM +0300, Denis V. Lunev wrote:
>> We should avoid to image file at migration end when BDRV_O_INACTIVE
> s/avoid to image/avoid writing to the image/ ?
yes
>> is set on the block driver state.
On 04/05/2017 06:37 PM, Eric Blake wrote:
> On 04/05/2017 10:18 AM, Denis V. Lunev wrote:
>> As long as BDRV_O_INACTIVE is set, the image file is only opened so we
>> have a file descriptor for it. We're definitely not supposed to modify
>> the image, it's still owned by
-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redhat.com>
CC: Max Reitz <mre...@redhat.com>
---
block.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block.c b/block.c
index 927ba89..9273741 100644
--- a/block.c
+++ b/block.c
@@ -3279,6 +3279,8 @@ int bdrv_truncat
From: Klim Kireev <pro...@virtuozzo.mipt.ru>
Signed-off-by: Klim Kireev <pro...@virtuozzo.mipt.ru>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redhat.com>
CC: Max Reitz <mre...@redhat.com>
---
include/block/block_int.h | 6 +++---
1 fi
First patch here is one we have agreed on during the initial discussion
about truncate() in parallels format driver, another one is simple
coding style change spotted by my student.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redhat.com>
CC: Max Reitz <mr
Stefan, here some obvious fixes for parallels image format. I am not quite
sure that they should go into 2.9, but it will be good if they will reach
2.9.1
Your opinion is very welcome here.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
De
(asserts are possible).
Let us keep this simple.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
---
block/parallels.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/parallels.c b/block/parallels.c
index 9dea
the image.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
---
block/parallels.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/block/parallels.c b/block/parallels.c
index 90acf79..9dea09e 100644
On 03/31/2017 04:47 PM, Max Reitz wrote:
> On 31.03.2017 15:13, Peter Maydell wrote:
>> Coverity (CID 1307776) points out that in the multiply:
>> space = to_allocate * s->tracks;
>> we are trying to calculate a 64 bit result but the types
>> of to_allocate and s->tracks mean that we actually
On 03/31/2017 05:56 PM, Max Reitz wrote:
> On 31.03.2017 16:54, Denis V. Lunev wrote:
>> On 03/31/2017 04:47 PM, Max Reitz wrote:
>>> On 31.03.2017 15:13, Peter Maydell wrote:
>>>> Coverity (CID 1307776) points out that in the multiply:
>>>> space = t
On 03/29/2017 05:11 PM, Kevin Wolf wrote:
> Am 29.03.2017 um 15:53 hat Denis V. Lunev geschrieben:
>> On 03/29/2017 01:41 PM, Kevin Wolf wrote:
>>> Am 28.03.2017 um 19:12 hat Denis V. Lunev geschrieben:
>>>> On 03/28/2017 07:26 PM, Kevin Wolf wrote:
>>&
On 03/29/2017 01:41 PM, Kevin Wolf wrote:
> Am 28.03.2017 um 19:12 hat Denis V. Lunev geschrieben:
>> On 03/28/2017 07:26 PM, Kevin Wolf wrote:
>>> [ Cc: qemu-block ]
>>>
>>> Am 27.03.2017 um 16:38 hat Denis V. Lunev geschrieben:
>>>> Parallels d
On 03/28/2017 01:55 PM, Dr. David Alan Gilbert wrote:
> * Kevin Wolf (kw...@redhat.com) wrote:
>> Am 25.02.2017 um 20:31 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> After migration all drives are inactive and savevm will fail with
>>>
>>> qemu-kvm: block/io.c:1406: bdrv_co_do_pwritev:
>>>
On 03/28/2017 07:26 PM, Kevin Wolf wrote:
> [ Cc: qemu-block ]
>
> Am 27.03.2017 um 16:38 hat Denis V. Lunev geschrieben:
>> Parallels driver should not call bdrv_truncate if the image was opened
>> in the read-only mode. Without the patch
>> qemu-img ch
) {
aio_poll(aio_context, true);
}
but rwco.ret is equal to 0 thus we have missed wakeup. Code investigation
reveals that we do not have performed aio_context_acquire() on this call
stack.
This patch adds missed lock.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redha
ce.
Here I use term 'RFC' as 'Can we start the discussion'?
> On 27.03.2017 17:35, Denis V. Lunev wrote:
>> Recently we expirience hang with iothreads enabled with the following
>> call trace:
>> Thread 1 (Thread 0x7fa95efebc80 (LWP 177117)):
>> 0 ppoll () from /lib
) {
aio_poll(aio_context, true);
}
but rwco.ret is equal to 0 thus we have missed wakeup. Code investigation
reveals that we do not have performed aio_context_acquire() on this call
stack.
This patch adds missed lock.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redha
opened
in the read-only mode.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
Reported-by: Edgar Kaziahmedov <e...@virtuozzo.mipt.ru>
CC: Stefan Hajnoczi <stefa...@redhat.com>
---
block/parallels.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
On 03/24/2017 12:20 AM, Kevin Wolf wrote:
> Am 23.03.2017 um 16:35 hat Denis V. Lunev geschrieben:
>> On 03/23/2017 06:04 PM, Kevin Wolf wrote:
>>> Am 23.03.2017 um 15:17 hat Eric Blake geschrieben:
>>>> On 03/23/2017 08:28 AM, Denis V. Lunev wrote:
>>>>
On 03/23/2017 06:04 PM, Kevin Wolf wrote:
> Am 23.03.2017 um 15:17 hat Eric Blake geschrieben:
>> On 03/23/2017 08:28 AM, Denis V. Lunev wrote:
>>> ZSDT compression algorithm consumes 3-5 times less CPU power with a
>> s/ZSDT/ZSTD/
>>
>>> comparable comre
ZSTD.
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Kevin Wolf <kw...@redhat.com>
CC: Max Reitz <mre...@redhat.com>
CC: Stefan Hajnoczi <stefa...@redhat.com>
CC: Fam Zheng <f...@redhat.com>
---
Actually this is very straightforward. May be we should implemen
ple - we should use 'M' as a suffix in default option value
instead of 'MiB'.
Signed-off-by: Edgar Kaziahmedov <e...@virtuozzo.mipt.ru>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Markus Armbruster <arm...@redhat.com>
CC: Stefan Hajnoczi <stefa...@redhat.com>
---
block/p
On 02/25/2017 10:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here are some migration related bugs, two about INACTIVE bdses and one
> use-after-free.
>
> I'm absolutely not sure, that these bugs should be fixed like I'm fixing,
> but problem definitely exists.
>
> Reset in stopped
;encinput buffer contains upto 4096
> bytes, but that data may cover both the header & payload. The
> handshake_end pointer refers to the end of the header region.
> So if we just pass encinput.offset, then handshake_process()
> will be searching part of the payload as well as the header.
> This might cause it do match the wrong data. I guess I should
> have made that clear in the commit, or even tput it in a
> separate commit
>
> Regards,
> Daniel
with this comment this is obviously correct :)
Reviewed-by: Denis V. Lunev <d...@openvz.org>
On 02/28/2017 01:48 PM, Daniel P. Berrange wrote:
> On Mon, Feb 27, 2017 at 08:14:56PM +, Daniel P. Berrange wrote:
>> According to RFC7230 Section 3.2, header field name is case-insensitive.
>> Convert the header data into all lowercase before doing string matching
>> on the headers.
>>
>>
On 02/28/2017 01:54 PM, Denis V. Lunev wrote:
> On 02/28/2017 01:48 PM, Daniel P. Berrange wrote:
>> On Mon, Feb 27, 2017 at 08:14:56PM +, Daniel P. Berrange wrote:
>>> According to RFC7230 Section 3.2, header field name is case-insensitive.
>>> Convert the hea
On 02/28/2017 12:20 AM, Eric Blake wrote:
> On 02/27/2017 02:14 PM, Daniel P. Berrange wrote:
>> According to RFC7230 Section 3.2, header field name is case-insensitive.
>> Convert the header data into all lowercase before doing string matching
>> on the headers.
>>
>> Signed-off-by: Daniel P.
On 02/27/2017 11:11 PM, Daniel P. Berrange wrote:
> On Mon, Jan 30, 2017 at 04:19:56PM +0300, Denis V. Lunev wrote:
>> From: Anton Nefedov <anton.nefe...@virtuozzo.com>
>>
>> According to RFC7230 Section 3.2, header field name is case-insensitive.
>>
>>
On 02/25/2017 10:31 PM, Vladimir Sementsov-Ogievskiy wrote:
> After migration all drives are inactive and savevm will fail with
>
> qemu-kvm: block/io.c:1406: bdrv_co_do_pwritev:
>Assertion `!(bs->open_flags & 0x0800)' failed.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
On 02/24/2017 04:31 PM, Paolo Bonzini wrote:
>
> On 24/02/2017 15:46, Marc-André Lureau wrote:
+if (ret < 0 && errno != EAGAIN) {
+if (tcp_chr_read_poll(chr) <= 0) {
+tcp_chr_disconnect(chr);
+return len;
>>> This change
On 02/20/2017 08:48 PM, Eric Blake wrote:
> On 02/20/2017 12:21 PM, Denis V. Lunev wrote:
>> From: Anton Nefedov <anton.nefe...@virtuozzo.com>
>>
>> Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <d.
From: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Paolo Bonzini <pbonz...@redhat.com>
CC: Eric Blake <ebl...@redhat.com>
---
qapi-schema.json | 12 ++
From: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Paolo Bonzini <pbonz...@redhat.com>
CC: Eric Blake <ebl...@redhat.com>
---
qapi/event.json | 4 ++--
1 fi
From: Anton Nefedov <anton.nefe...@virtuozzo.com>
Do not make some foreign function do it.
Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Paolo Bonzini <pbonz...@redhat.com>
CC: Eric Blake <ebl...@redh
This is a set of followup patches requested by Eric Blake.
Signed-off-by: Anton Nefedov <anton.nefe...@virtuozzo.com>
Signed-off-by: Denis V. Lunev <d...@openvz.org>
CC: Paolo Bonzini <pbonz...@redhat.com>
CC: Eric Blake <ebl...@redhat.com>
Anton Nefedov
On 02/20/2017 07:10 PM, Paolo Bonzini wrote:
>
> On 16/02/2017 20:36, Eric Blake wrote:
>> On that grounds, you already need the 'if (info)' for more than just the
>> free, so this code motion is no longer quite as important. But now I'm
>> noticing that it looks weird because you are freeing an
On 02/20/2017 12:15 PM, Kevin Wolf wrote:
> Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben:
>> On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 17.02.2017 17:24, Kevin Wolf wrote:
>>>> Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben:
>&
601 - 700 of 2500 matches
Mail list logo
