* Maxim Levitsky (mlevi...@redhat.com) wrote:
> On Mon, 2020-02-03 at 19:57 +, Dr. David Alan Gilbert wrote:
> > * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > > This patch series is bunch of cleanups to the hmp monitor code.
> > > It mostly moves the blockdev related hmp handlers to its
On 20.01.20 10:09, Vladimir Sementsov-Ogievskiy wrote:
> ping
Sorry, I only got to patch 5 so far (without major complaints). I’ll
have to pack things up for the weekend now and I’ll be on PTO next week,
so I won’t get to review the final two patches before Feb 17, I’m afraid...
Max
On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> offset/bytes pair is more usual naming in block layer, let's use it.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/block/block-copy.h | 2 +-
> block/block-copy.c | 80 +++---
> 2
On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> We have a lot of "chunk_end - start" invocations, let's switch to
> bytes/cur_bytes scheme instead.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/block/block-copy.h | 4 +--
> block/block-copy.c | 68
On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> Split block_copy_find_inflight_req to be used in seprate.
*separate, but separate what?
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/block-copy.c | 31 +++
> 1 file changed, 19 insertions(+), 12
On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> Use bdrv_block_status_above to chose effective chunk size and to handle
> zeroes effectively.
>
> This substitutes checking for just being allocated or not, and drops
> old code path for it. Assistance by backup job is dropped too, as
>
On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> In block_copy_do_copy we fallback to read+write if copy_range failed.
> In this case copy_size is larger than defined for buffered IO, and
> there is corresponding commit. Still, backup copies data cluster by
> cluster, and most of requests
07.02.2020 19:47, Stefan Hajnoczi wrote:
On Thu, Feb 06, 2020 at 07:42:45PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Commit 7a3f542fbd "block/io: refactor padding" occasionally dropped
aligning for zero-length request: bdrv_init_padding() blindly return
false if bytes == 0, like there is
ng branch 'remotes/maxreitz/tags/pull-block-2020-02-06'
> into staging (2020-02-06 16:22:05 +)
>
> are available in the Git repository at:
>
> https://gitlab.com/philmd/qemu.git tags/python-next-20200207
>
> for you to fetch changes up to 66e7dde18cc4085ca47124be4ca08fa8e6bcdd3a:
&g
On Thu, Feb 06, 2020 at 07:42:45PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Commit 7a3f542fbd "block/io: refactor padding" occasionally dropped
> aligning for zero-length request: bdrv_init_padding() blindly return
> false if bytes == 0, like there is nothing to align.
>
> This leads the
07.02.2020 19:30, Max Reitz wrote:
On 07.02.20 17:12, Vladimir Sementsov-Ogievskiy wrote:
backup-top "supports" write-unchanged, by skipping CBW operation in
backup_top_co_pwritev. But it forgets to do the same in
backup_top_co_pwrite_zeroes, as well as declare support for
On 07.02.20 17:12, Vladimir Sementsov-Ogievskiy wrote:
> backup-top "supports" write-unchanged, by skipping CBW operation in
> backup_top_co_pwritev. But it forgets to do the same in
> backup_top_co_pwrite_zeroes, as well as declare support for
> BDRV_REQ_WRITE_UNCHANGED.
>
> Fix this, and, while
On 2/7/20 5:07 PM, Markus Armbruster wrote:
Kevin Wolf writes:
Am 07.02.2020 um 15:01 hat Markus Armbruster geschrieben:
Philippe Mathieu-Daudé writes:
List this file in the proper section, so maintainers get
notified when it is modified.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc:
On Fri, Feb 07, 2020 at 11:48:05AM +0300, Denis Plotnikov wrote:
>
>
> On 05.02.2020 14:19, Stefan Hajnoczi wrote:
> > On Tue, Feb 04, 2020 at 12:59:04PM +0300, Denis Plotnikov wrote:
> > >
> > > On 30.01.2020 17:58, Stefan Hajnoczi wrote:
> > > > On Wed, Jan 29, 2020 at 05:07:00PM +0300, Denis
backup-top "supports" write-unchanged, by skipping CBW operation in
backup_top_co_pwritev. But it forgets to do the same in
backup_top_co_pwrite_zeroes, as well as declare support for
BDRV_REQ_WRITE_UNCHANGED.
Fix this, and, while being here, declare also support for flags
supported by source
Kevin Wolf writes:
> Am 07.02.2020 um 15:01 hat Markus Armbruster geschrieben:
>> Philippe Mathieu-Daudé writes:
>>
>> > List this file in the proper section, so maintainers get
>> > notified when it is modified.
>> >
>> > Signed-off-by: Philippe Mathieu-Daudé
>> > ---
>> > Cc: Kevin Wolf
>>
07.02.2020 18:12, Max Reitz wrote:
On 07.02.20 15:57, Eric Blake wrote:
On 2/7/20 8:41 AM, Max Reitz wrote:
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so
On 07.02.20 16:16, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 18:03, Max Reitz wrote:
>> On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
>>> 07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 13:33, Max Reitz wrote:
>>
On 07.02.20 14:55, Daniel P. Berrangé wrote:
> When initializing the LUKS header the size with default encryption
> parameters will currently be 2068480 bytes. This is rounded up to
> a multiple of the cluster size, 2081792, with 64k sectors. If the
> end of the header is not the same as the end
.
The following changes since commit 863d2ed5823f90c42dcd481687cc99cbc9c4a17c:
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2020-02-06'
into staging (2020-02-06 16:22:05 +)
are available in the Git repository at:
https://gitlab.com/philmd/qemu.git tags/python-next-20200207
On 07.02.20 15:57, Eric Blake wrote:
> On 2/7/20 8:41 AM, Max Reitz wrote:
>
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so they would specify
07.02.2020 18:03, Max Reitz wrote:
On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir
On 07.02.20 15:53, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 17:41, Max Reitz wrote:
>> On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
>>> 07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>
Use the program search path to find the Python 3 interpreter.
Patch created mechanically by running:
$ sed -i "s,^#\!/usr/bin/\(env\ \)\?python$,#\!/usr/bin/env python3," \
$(git grep -lF '#!/usr/bin/env python' \
| xargs grep -L 'if __name__.*__main__')
Reported-by: Vladimir
On 2/7/20 8:41 AM, Max Reitz wrote:
I could imagine a user creating a qcow2 image on some block device with
preallocation where we cannot verify that the result will be zero. But
they want qemu not to zero the device, so they would specify
--target-is-zero.
If user create image, setting
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
> 07.02.2020 13:33, Max Reitz wrote:
>> On 04.02.20 15:23, Eric Blake wrote:
>>> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>>>
> I understand that it is safer to have restrictions now and lift them
> later, than to allow
07.02.2020 17:41, Max Reitz wrote:
On 07.02.20 13:07, Vladimir Sementsov-Ogievskiy wrote:
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
On 2/7/20 7:55 AM, Daniel P. Berrangé wrote:
When initializing the LUKS header the size with default encryption
parameters will currently be 2068480 bytes. This is rounded up to
a multiple of the cluster size, 2081792, with 64k sectors. If the
end of the header is not the same as the end of the
Am 07.02.2020 um 15:01 hat Markus Armbruster geschrieben:
> Philippe Mathieu-Daudé writes:
>
> > List this file in the proper section, so maintainers get
> > notified when it is modified.
> >
> > Signed-off-by: Philippe Mathieu-Daudé
> > ---
> > Cc: Kevin Wolf
> > Cc: Max Reitz
> > Cc:
Philippe Mathieu-Daudé writes:
> List this file in the proper section, so maintainers get
> notified when it is modified.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: Kevin Wolf
> Cc: Max Reitz
> Cc: qemu-block@nongnu.org
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
On 2/7/20 1:39 PM, Philippe Mathieu-Daudé wrote:
On 2/7/20 12:51 PM, Peter Maydell wrote:
On Thu, 6 Feb 2020 at 21:21, Philippe Mathieu-Daudé
wrote:
Hi Peter,
I prepared this series on behalf of Eduardo and
Cleber (one of them will ack this cover).
Regards,
Phil.
The following changes
When initializing the LUKS header the size with default encryption
parameters will currently be 2068480 bytes. This is rounded up to
a multiple of the cluster size, 2081792, with 64k sectors. If the
end of the header is not the same as the end of the cluster we fill
the extra space with zeros.
On Fri, Feb 7, 2020 at 2:30 PM Philippe Mathieu-Daudé wrote:
>
> Cc'ing qemu-block@
>
> On 2/7/20 12:51 PM, Peter Maydell wrote:
> > On Thu, 6 Feb 2020 at 21:21, Philippe Mathieu-Daudé
> > wrote:
> >>
> >> Hi Peter,
> >>
> >> I prepared this series on behalf of Eduardo and
> >> Cleber (one of
Cc'ing qemu-block@
On 2/7/20 12:51 PM, Peter Maydell wrote:
On Thu, 6 Feb 2020 at 21:21, Philippe Mathieu-Daudé wrote:
Hi Peter,
I prepared this series on behalf of Eduardo and
Cleber (one of them will ack this cover).
Regards,
Phil.
The following changes since commit
07.02.2020 13:33, Max Reitz wrote:
On 04.02.20 15:23, Eric Blake wrote:
On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
I understand that it is safer to have restrictions now and lift them
later, than to allow use of the option at any time and leave room for
the user to shoot
On 05.02.20 12:02, David Edmondson wrote:
> In many cases the target of a convert operation is a newly provisioned
> target that the user knows is blank (reads as zero). In this situation
> there is no requirement for qemu-img to wastefully zero out the entire
> device.
>
> Add a new option,
On 07.02.20 11:30, Philippe Mathieu-Daudé wrote:
> List this file in the proper section, so maintainers get
> notified when it is modified.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> Cc: Kevin Wolf
> Cc: Max Reitz
> Cc: qemu-block@nongnu.org
> ---
> MAINTAINERS | 2 ++
> 1 file
On 04.02.20 15:23, Eric Blake wrote:
> On 2/4/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:
>
>>> I understand that it is safer to have restrictions now and lift them
>>> later, than to allow use of the option at any time and leave room for
>>> the user to shoot themselves in the foot with no
List this file in the proper section, so maintainers get
notified when it is modified.
Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-block@nongnu.org
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
On 20.01.20 09:50, Peter Krempa wrote:
> When a management application manages node names there's no reason to
> recurse into backing images in the output of query-named-block-nodes.
>
> Add a parameter to the command which will return just the top level
> structs.
>
> Signed-off-by: Peter
On 05.02.2020 14:19, Stefan Hajnoczi wrote:
On Tue, Feb 04, 2020 at 12:59:04PM +0300, Denis Plotnikov wrote:
On 30.01.2020 17:58, Stefan Hajnoczi wrote:
On Wed, Jan 29, 2020 at 05:07:00PM +0300, Denis Plotnikov wrote:
The goal is to reduce the amount of requests issued by a guest on
1M
On 06.02.20 19:33, Lukáš Doktor wrote:
> Dne 06. 02. 20 v 17:59 Max Reitz napsal(a):
>> On 06.02.20 17:48, Eric Blake wrote:
>>> On 2/6/20 10:37 AM, Max Reitz wrote:
[...]
OTOH, would it work if we just did a %s/localhost/127.0.0.1/ in the
test? We have specific cases for IPv6, so I
42 matches
Mail list logo
