Re: [Qemu-block] [Qemu-devel] [PATCH v4 12/13] fdc-test: Avoid deprecated 'change' command

t;); > > dir = inb(FLOPPY_BASE + reg_dir); > assert_bit_set(dir, DSKCHG); > @@ -564,7 +564,7 @@ int main(int argc, char **argv) > /* Run the tests */ > g_test_init(, , NULL); > > -qtest_start(NULL); > +qtest_start("-device floppy,id=floppy0"); > qtest_irq_intercept_in(global_qtest, "ioapic"); > qtest_add_func("/fdc/cmos", test_cmos); > qtest_add_func("/fdc/no_media_on_start", test_no_media_on_start); > yay Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 5/9] block: introduce bdrv_try_set_read_only()

On 04/05/2017 02:28 PM, Jeff Cody wrote: > Introduce try function for setting read_only flags. Will return < 0 on > error, with appropriate Error value set. Does not alter any flags. > > Signed-off-by: Jeff Cody > --- > block.c | 14 +- >

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 2/9] block: do not set BDS read_only if copy_on_read enabled

On 04/05/2017 02:28 PM, Jeff Cody wrote: > A few block drivers will set the BDS read_only flag from their > .bdrv_open() function. This means the bs->read_only flag could > be set after we enable copy_on_read, as the BDRV_O_COPY_ON_READ > flag check occurs prior to the call to

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 3/9] block: honor BDRV_O_ALLOW_RDWR when clearing bs->read_only

On 04/05/2017 02:28 PM, Jeff Cody wrote: > The BDRV_O_ALLOW_RDWR flag allows / prohibits the changing of > the BDS 'read_only' state, but there are a few places where it > is ignored. In the bdrv_set_read_only() helper, make sure to > honor the flag. > > Signed-off-by: Jeff Cody

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 6/9] block: use bdrv_try_set_read_only() during reopen

On 04/05/2017 02:28 PM, Jeff Cody wrote: > Signed-off-by: Jeff Cody > --- > block.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/block.c b/block.c > index ad958b9..3245fae 100644 > --- a/block.c > +++ b/block.c > @@ -2785,6 +2785,7

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 4/9] block: code movement

On 04/05/2017 02:28 PM, Jeff Cody wrote: > Move bdrv_is_read_only() up with its friends. > > Signed-off-by: Jeff Cody > --- > block.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/block.c b/block.c > index 4a61ff0..8bfe7f4 100644 > ---

Re: [Qemu-block] [PATCH v3 12/13] fdc-test: Avoid deprecated 'change' command

with -device isa-fdc,id=foobar -device floppy,bus=foobar.0,unit=1 Or you could do nothing, and I won't tell anyone. --js > Signed-off-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com> > > --- > v3: update commit message to point out that we a

Re: [Qemu-block] [Qemu-devel] [PATCH 01/12] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

_new0(BlockDirtyInfoList, 1); > -info->count = bdrv_get_dirty_count(bm); > +info->count = bdrv_get_dirty_count(bm) << BDRV_SECTOR_BITS; > info->granularity = bdrv_dirty_bitmap_granularity(bm); > info->has_name = !!bm->name; >

Re: [Qemu-block] [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/12/2017 07:36 PM, Eric Blake wrote: > On 04/12/2017 05:47 PM, John Snow wrote: >> >> >> On 04/12/2017 01:49 PM, Eric Blake wrote: >>> We had several functions that no one was using, and which used >>> sector-based interfaces. I'm trying to conver

Re: [Qemu-block] [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/12/2017 01:49 PM, Eric Blake wrote: > We had several functions that no one was using, and which used > sector-based interfaces. I'm trying to convert towards byte-based > interfaces, so it's easier to just drop the unused functions: > > bdrv_dirty_bitmap_size > bdrv_dirty_bitmap_get_meta

Re: [Qemu-block] [Qemu-devel] [PATCH 05/12] dirty-bitmap: Set iterator start by offset, not sector

ext_offset); > next_dirty = bdrv_dirty_iter_next(s->dbi) * BDRV_SECTOR_SIZE; > } > assert(next_dirty == next_offset); > @@ -779,7 +779,7 @@ static void coroutine_fn mirror_run(void *opaque) > } > > assert(!s->dbi); > -s->dbi = bdrv_dirty_iter_new(s->dirty_bitmap, 0); > +s->dbi = bdrv_dirty_iter_new(s->dirty_bitmap); > for (;;) { > uint64_t delay_ns = 0; > int64_t cnt, delta; > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 06/12] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

ZE; > +next_dirty = bdrv_dirty_iter_next(s->dbi); > if (next_dirty > next_offset || next_dirty < 0) { > /* The bitmap iterator's cache is stale, refresh it */ > bdrv_set_dirty_iter(s->dbi, next_offset); > -next_dirty = bdrv_dirty_iter_next(s->dbi) * BDRV_SECTOR_SIZE; > +next_dirty = bdrv_dirty_iter_next(s->dbi); > } > assert(next_dirty == next_offset); > nb_chunks++; > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On 04/12/2017 04:46 PM, Jeff Cody wrote: > > This occurs on v2.9.0-rc4, but not on v2.8.0. > > When running QEMU with an iothread, and then performing a block-mirror, if > we do a system-reset after the BLOCK_JOB_READY event has emitted, qemu > becomes deadlocked. > > The block job is not

Re: [Qemu-block] [Qemu-devel] [PATCH 02/12] migration: Don't lose errno across aio context changes

bmds->dirty_bitmap = bdrv_create_dirty_bitmap(blk_bs(bmds->blk), >BLOCK_SIZE, NULL, > NULL); > +ret = -errno; > aio_context_release(blk_get_aio_context(bmds->blk)); > if (!bmds->dirty_bitmap) { > -ret = -errno; > goto fail; > } > } > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 04/12] dirty-bitmap: Track size in bytes

> @@ -419,7 +422,7 @@ void bdrv_clear_dirty_bitmap(BdrvDirtyBitmap *bitmap, > HBitmap **out) > hbitmap_reset_all(bitmap->bitmap); > } else { > HBitmap *backup = bitmap->bitmap; > -bitmap->bitmap = hbitmap_alloc(bitmap->size, > +bitmap->bitmap = hbitmap_alloc(bitmap->size >> BDRV_SECTOR_BITS, > hbitmap_granularity(backup)); > *out = backup; > } > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 10/12] mirror: Switch mirror_dirty_init() to byte-based iteration

0) { > return ret; > } > > -n = DIV_ROUND_UP(count, BDRV_SECTOR_SIZE); > -assert(n > 0); > +count = QEMU_ALIGN_UP(count, BDRV_SECTOR_SIZE); > if (ret == 1) { > - bdrv_set_dirty_bitmap(s->dirty_bitmap, > - sector_num * BDRV_SECTOR_SIZE, > - n * BDRV_SECTOR_SIZE); > +bdrv_set_dirty_bitmap(s->dirty_bitmap, offset, count); > } > -sector_num += n; > +offset += count; > } > return 0; > } > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 09/12] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

_cb, blk); > > -bdrv_reset_dirty_bitmap(bmds->dirty_bitmap, cur_sector, nr_sectors); > +bdrv_reset_dirty_bitmap(bmds->dirty_bitmap, cur_sector * > BDRV_SECTOR_SIZE, > +nr_sectors * BDRV_SECTOR_SIZE); > aio_context_release(blk_get_aio_context(bmds->blk)); > qemu_mutex_unlock_iothread(); > > @@ -575,7 +576,9 @@ static int mig_save_device_dirty(QEMUFile *f, > BlkMigDevState *bmds, > g_free(blk); > } > > -bdrv_reset_dirty_bitmap(bmds->dirty_bitmap, sector, nr_sectors); > +bdrv_reset_dirty_bitmap(bmds->dirty_bitmap, > +sector * BDRV_SECTOR_SIZE, > +nr_sectors * BDRV_SECTOR_SIZE); > sector += nr_sectors; > bmds->cur_dirty = sector; > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

job_sleep_ns(>common, QEMU_CLOCK_REALTIME, delay_ns); > if (block_job_is_cancelled(>common)) { > diff --git a/migration/block.c b/migration/block.c > index 9a9c214..3daa5c7 100644 > --- a/migration/block.c > +++ b/migration/block.c > @@ -672,7 +672,7 @@ static int64_t get_remaining_dirty(void) > aio_context_release(blk_get_aio_context(bmds->blk)); > } > > -return dirty << BDRV_SECTOR_BITS; > +return dirty; > } > > /* Called with iothread lock taken. */ > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 07/12] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

job_sleep_ns(>common, QEMU_CLOCK_REALTIME, delay_ns); > if (block_job_is_cancelled(>common)) { > diff --git a/migration/block.c b/migration/block.c > index 9a9c214..3daa5c7 100644 > --- a/migration/block.c > +++ b/migration/block.c > @@ -672,7 +672,7 @@ static int64_t get_remaining_dirty(void) > aio_context_release(blk_get_aio_context(bmds->blk)); > } > > -return dirty << BDRV_SECTOR_BITS; > +return dirty; > } > > /* Called with iothread lock taken. */ > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 11/12] dirty-bitmap: Switch bdrv_set_dirty() to bytes

> +bdrv_set_dirty(bs, offset, bytes); > > if (bs->wr_highest_offset < offset + bytes) { > bs->wr_highest_offset = offset + bytes; > @@ -2535,8 +2534,7 @@ int coroutine_fn bdrv_co_pdiscard(BlockDriverState *bs, > int64_t offset, > ret = 0; > o

Re: [Qemu-block] [Qemu-devel] [PATCH 08/12] dirty-bitmap: Change bdrv_get_dirty() to take bytes

v_get_dirty(bs, bmds->dirty_bitmap, sector * > BDRV_SECTOR_SIZE)) { This one is a little weirder now though, isn't it? We're asking for the dirty status of a single byte, technically. In practice, the scaling factor will always cover the entire sector, but it reads a lot jankier now. > if (total_sectors - sector < BDRV_SECTORS_PER_DIRTY_CHUNK) { > nr_sectors = total_sectors - sector; > } else { > Oh well, it was always janky... Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 12/12] dirty-bitmap: Convert internal hbitmap size/granularity

bytes); > } > } > > @@ -497,12 +484,12 @@ void bdrv_set_dirty(BlockDriverState *bs, int64_t > offset, int64_t bytes) > */ > void bdrv_set_dirty_iter(BdrvDirtyBitmapIter *iter, int64_t offset) > { > -hbitmap_iter_init(>hbi, iter->hbi.hb, offset >> BDRV_SECTOR_BITS); > +hbitmap_iter_init(>hbi, iter->hbi.hb, offset); > } > > int64_t bdrv_get_dirty_count(BdrvDirtyBitmap *bitmap) > { > -return hbitmap_count(bitmap->bitmap) << BDRV_SECTOR_BITS; > +return hbitmap_count(bitmap->bitmap); > } > > int64_t bdrv_get_meta_dirty_count(BdrvDirtyBitmap *bitmap) > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH] progress: Show current progress on SIGINFO

On 04/13/2017 04:38 PM, Max Reitz wrote: > On 08.02.2017 00:57, Max Reitz wrote: >> Currently we only print progress information on retrieval of SIGUSR1. >> Some systems have a dedicated SIGINFO for this, however, so it should be >> handled appropriately if it is available. >> >> Buglink:

Re: [Qemu-block] [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

On 04/13/2017 06:19 AM, Denis V. Lunev wrote: > 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. > > The

Re: [Qemu-block] [PATCH RFC 0/3] block: Backdoor to skip image locking in qemu-io/qemu-img

On 03/13/2017 10:39 PM, Fam Zheng wrote: > Hi Kevin, > > This tries to capture your idea to add a explicit command option in qemu-io > and > qemu-img for user to specify "expect inconsistent data when reading image". > It's stored as a BDRV_O_ flag internally, I don't know if there is a

Re: [Qemu-block] [PATCH for-2.10] Revert "block/io: Comment out permission assertions"

On 04/13/2017 10:34 AM, Max Reitz wrote: > On 13.04.2017 15:28, Stefan Hajnoczi wrote: >> On Tue, Apr 11, 2017 at 05:52:26PM +0200, Max Reitz wrote: >>> This reverts commit e3e0003a8f6570aba1421ef99a0b383a43371a74. >>> >>> This commit was necessary for the 2.9 release because we were unable to

Re: [Qemu-block] [Qemu-devel] [PATCH 03/12] dirty-bitmap: Drop unused functions

On 04/13/2017 05:19 AM, Vladimir Sementsov-Ogievskiy wrote: > 13.04.2017 02:40, John Snow wrote: >> >> On 04/12/2017 07:36 PM, Eric Blake wrote: >>> On 04/12/2017 05:47 PM, John Snow wrote: >>>> >>>> On 04/12/2017 01:49 PM, Eric Blake wrote: >

Re: [Qemu-block] [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()

On 04/13/2017 11:02 AM, Jeff Cody wrote: > On Thu, Apr 13, 2017 at 03:39:59PM +0100, Stefan Hajnoczi wrote: >> On Thu, Apr 13, 2017 at 01:45:55PM +0800, Paolo Bonzini wrote: >>> >>> >>> On 13/04/2017 09:11, Jeff Cody wrote: > It didn't make it into 2.9-rc4 because of limited time. :( >

Re: [Qemu-block] [PATCH 16/17] block: Make bdrv_is_allocated() byte-based

On 04/19/2017 01:54 PM, Eric Blake wrote: > On 04/18/2017 05:15 PM, John Snow wrote: > >>> @@ -279,9 +280,9 @@ static int mig_save_device_bulk(QEMUFile *f, >>> BlkMigDevState *bmds) >>> /* Skip unallocated sectors; intentionally treats failure as &g

Re: [Qemu-block] [PATCH 16/17] block: Make bdrv_is_allocated() byte-based

On 04/11/2017 06:29 PM, Eric Blake wrote: > We are gradually moving away from sector-based interfaces, towards > byte-based. In the common case, allocation is unlikely to ever use > values that are not naturally sector-aligned, but it is possible > that byte-based values will let us be more

Re: [Qemu-block] [PATCH 02/17] trace: Show blockjob actions via bytes, not sectors

quot; bytes %" PRIu64 " ret %d" > mirror_yield(void *s, int64_t cnt, int buf_free_count, int in_flight) "s %p > dirty count %"PRId64" free buffers %d in_flight %d" > -mirror_yield_in_flight(void *s, int64_t sector_num, int in_flight) "s %p > sector_num %"PRId64" in_flight %d" > +mirror_yield_in_flight(void *s, int64_t offset, int in_flight) "s %p offset > %" PRId64 " in_flight %d" > > # block/backup.c > -backup_do_cow_enter(void *job, int64_t start, int64_t sector_num, int > nb_sectors) "job %p start %"PRId64" sector_num %"PRId64" nb_sectors %d" > -backup_do_cow_return(void *job, int64_t sector_num, int nb_sectors, int ret) > "job %p sector_num %"PRId64" nb_sectors %d ret %d" > +backup_do_cow_enter(void *job, int64_t start, int64_t offset, uint64_t > bytes) "job %p start %" PRId64 " offset %" PRId64 " bytes %" PRIu64 > +backup_do_cow_return(void *job, int64_t offset, uint64_t bytes, int ret) > "job %p offset %" PRId64 " bytes %" PRIu64 " ret %d" > backup_do_cow_skip(void *job, int64_t start) "job %p start %"PRId64 > backup_do_cow_process(void *job, int64_t start) "job %p start %"PRId64 > backup_do_cow_read_fail(void *job, int64_t start, int ret) "job %p start > %"PRId64" ret %d" I guess these three were "cluster" based, but you didn't need to change anything to assert them as byte-based. > Under the assumption that it's okay to change tracing output without being able to differentiate between new and old output: Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH 01/17] blockjob: Track job ratelimits via bytes, not sectors

; > if (copy && s->common.speed) { > -delay_ns = ratelimit_calculate_delay(>limit, n); > + delay_ns = ratelimit_calculate_delay(>limit, > + n * BDRV_SECTOR_SIZE); Same kind of comment here. > } > } > > @@ -220,7 +221,7 @@ static void stream_set_speed(BlockJob *job, int64_t > speed, Error **errp) > error_setg(errp, QERR_INVALID_PARAMETER, "speed"); > return; > } > -ratelimit_set_speed(>limit, speed / BDRV_SECTOR_SIZE, SLICE_TIME); > +ratelimit_set_speed(>limit, speed, SLICE_TIME); > } > > static const BlockJobDriver stream_job_driver = { > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH 16/17] block: Make bdrv_is_allocated() byte-based

On 04/19/2017 05:12 PM, Eric Blake wrote: > On 04/19/2017 03:32 PM, John Snow wrote: > >>> @@ -279,9 +280,9 @@ static int mig_save_device_bulk(QEMUFile *f, >>> BlkMigDevState *bmds) >>> /* Skip unallocated sectors; intentionally treats failure as &g

Re: [Qemu-block] [PATCH] qemu-img: improve convert_iteration_sectors()

et. If the target also has_zero_init, we can just skip this sector. If it doesn't, we want to copy zeroes. If has_zero_init is false and we have unallocated data on the source... what are we doing? Copying random debris? I'm pretty confused, but I'm pretty sure your patch doesn't actually change

Re: [Qemu-block] [Qemu-devel] [PATCH v2 02/21] sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE

cornelia.h...@de.ibm.com> > Cc: David Gibson <da...@gibson.dropbear.id.au> > Cc: "Edgar E. Iglesias" <edgar.igles...@gmail.com> > Cc: Eduardo Habkost <ehabk...@redhat.com> > Cc: Frank Blaschka <frank.blasc...@de.ibm.com> > Cc: Gabriel L. Somlo <so...@cmu.

Re: [Qemu-block] [PATCH v2 6/6] tests/block-job-txn: Don't start block job before adding to txn

ter cannot be handled correctly. >> >> Move the block_job_start() calls to callers after >> block_job_txn_add_job() calls. >> >> Signed-off-by: Fam Zheng <f...@redhat.com> >> --- >> tests/test-blockjob-txn.c | 6 +- >> 1 file changed, 5 insert

Re: [Qemu-block] [PATCH 00/17] make bdrv_is_allocated[_above] byte-based

5 ++- > qemu-io-cmds.c | 57 > block/trace-events | 14 +- > 14 files changed, 381 insertions(+), 371 deletions(-) Shame, you added ten lines! > Patches 1-15: Reviewed-by: John Snow <js...@redhat.com> 9: Is there a good reason for a void fn()

Re: [Qemu-block] [PATCH 13/17] backup: Switch block_backup.h to byte-based

On 04/11/2017 06:29 PM, Eric Blake wrote: > We are gradually converting to byte-based interfaces, as they are > easier to reason about than sector-based. Continue by converting > the public interface to backup jobs (no semantic change), including > a change to CowRequest to track by bytes

Re: [Qemu-block] [PATCH 16/17] block: Make bdrv_is_allocated() byte-based

On 04/11/2017 06:29 PM, Eric Blake wrote: > We are gradually moving away from sector-based interfaces, towards > byte-based. In the common case, allocation is unlikely to ever use > values that are not naturally sector-aligned, but it is possible > that byte-based values will let us be more

Re: [Qemu-block] [PATCH 17/17] block: Make bdrv_is_allocated_above() byte-based

delay_ns = ratelimit_calculate_delay(>limit, n); > } > } > > diff --git a/qemu-img.c b/qemu-img.c > index 2f21d69..d96b4d6 100644 > --- a/qemu-img.c > +++ b/qemu-img.c > @@ -1448,12 +1448,16 @@ static int img_compare(int argc, char **argv) > } > > for (;;) { > +int64_t count; > + > nb_sectors = sectors_to_process(total_sectors_over, sector_num); > if (nb_sectors <= 0) { > break; > } > -ret = bdrv_is_allocated_above(blk_bs(blk_over), NULL, sector_num, > - nb_sectors, ); > +ret = bdrv_is_allocated_above(blk_bs(blk_over), NULL, > + sector_num * BDRV_SECTOR_SIZE, > + nb_sectors * BDRV_SECTOR_SIZE, > + ); > if (ret < 0) { > ret = 3; > error_report("Sector allocation test failed for %s", > @@ -1461,7 +1465,7 @@ static int img_compare(int argc, char **argv) > goto out; > > } > -nb_sectors = pnum; > +nb_sectors = DIV_ROUND_UP(count, BDRV_SECTOR_SIZE); > if (ret) { > ret = check_empty_sectors(blk_over, sector_num, nb_sectors, >filename_over, buf1, quiet); > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v3] qemu-iotests: add a "how to" to ./README

ewed-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: Philippe Mathieu-Daudé <f4...@amsat.org> > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> Already overkill, but I read it all anyway; so: Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 1/1] qemu-iotests/109: Fix lock race condition

; attempt to open the TEST_IMG file before it can secure a lock on it. > > This attempts a more graceful shutdown, and waits for the QEMU process > to exit. > > Signed-off-by: Cleber Rosa <cr...@redhat.com> Reviewed-by: John Snow <js...@redhat.com> Thanks for this, it was driving me batty.

Re: [Qemu-block] [Qemu-devel] [PATCH v2 00/10] Correct two minor QMP interface design flaws

On 08/16/2017 05:41 PM, Eric Blake wrote: > On 08/16/2017 04:34 PM, John Snow wrote: >> Looks like this series got no replies (maybe a failure of my mail >> filtering?) but it has since been merged, so purely for my own selfish >> purposes; > > No re

Re: [Qemu-block] [Qemu-devel] [PATCH v5 14/18] qcow2: Switch qcow2_measure() to byte-based iteration

right!? > Signed-off-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v5 13/18] mirror: Switch mirror_dirty_init() to byte-based iteration

hat.com> > Looks like we just pick up a touch more cleanup here. Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/9] block: -device drive= fixes

| 13 ++ > tests/qemu-iotests/067.out | 40 > tests/qemu-iotests/186 | 147 + > tests/qemu-iotests/186.out | 489 > + > tests/qemu-iotests/group | 1 + > 12 files changed, 735 insertions(+), 10 deletions(-) > create mode 100755 tests/qemu-iotests/186 > create mode 100644 tests/qemu-iotests/186.out > Series: Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v5 05/18] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

sectors. > > Use is_power_of_2() while at it, instead of open-coding that, and > add an assertion where bdrv_getlength() should not fail. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH] block: check BlockDriverState object before dereference

On 07/11/2017 01:08 PM, P J P wrote: > From: Prasad J Pandit > > When processing ATA_CACHE_FLUSH ide controller command, > BlockDriverState object could be null. Add check to avoid > null pointer dereference. > This happens through 0xE7, what QEMU calls

Re: [Qemu-block] [PATCH] iotests: Remove a few tests from 'quick' group

rw auto > Seems about as scientific as the existing methods used to define the quick group, so why not? Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH 1/2] nbd: Trace client command being sent

On 07/14/2017 02:32 PM, Eric Blake wrote: > Make the client trace slightly more legible by including the name > of the command being sent. > > Signed-off-by: Eric Blake <ebl...@redhat.com> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH 2/2] nbd: Fix server reply to NBD_OPT_EXPORT_NAME of older clients

On 07/14/2017 02:32 PM, Eric Blake wrote: > A typo in commit 23e099c set the size of buf[] used in response > to NBD_OPT_EXPORT_NAME according to the length needed for old-style > negotiation (4 bytes of flag information) instead of the intended > 2 bytes used in new style. If the client

Re: [Qemu-block] [PATCH] nbd: Fix iotests failure due to changed client error message

, but if it proves problematic in practice, we'll have > to tweak or sanitize the output somehow. > > Reported-by: Kevin Wolf <kw...@redhat.com> > Signed-off-by: Eric Blake <ebl...@redhat.com> Thanks, fixes it up for me. Tested-by: John Snow <js...@redhat.com> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH v2] docs: add qemu-block-drivers(7) man page

e called > docs/qemu-block-drivers.texi. This file can also be built as a > stand-alone document (man, html, etc). > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com> > --- Ping for 2.10, or no? --js

Re: [Qemu-block] [Qemu-devel] [PATCH v2 2/2] nbd: Fix server reply to NBD_OPT_EXPORT_NAME of older clients

client->exp->nbdflags | myflags); > stq_be_p(buf + 8, NBD_CLIENT_MAGIC); > stq_be_p(buf + 16, client->exp->size); > -stw_be_p(buf + 26, client->exp->nbdflags | myflags); > +stl_be_p(buf + 24, client->exp->nbdflags | myflags); Makes sense to me. > > if (nbd_write(client->ioc, buf, sizeof(buf), errp) < 0) { > error_prepend(errp, "write failed: "); > Thanks, Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v5 2/2] live-block-ops.txt: Rename, rewrite, and improve it

On 07/07/2017 06:46 AM, Kashyap Chamarthy wrote: > Thanks for your patience in review. Much appreciated (including the > grammar corrections)! > > I'll wait for the rest of your comments before I spin a v6. > > [...] Thank *you* for exercising the necessary patience to make incredibly nice

Re: [Qemu-block] [Qemu-devel] [PATCH v22 25/30] qmp: add x-debug-block-dirty-bitmap-sha256

On 07/07/2017 09:53 AM, Markus Armbruster wrote: > Vladimir Sementsov-Ogievskiy writes: > >> 07.07.2017 12:00, Markus Armbruster wrote: >>> "Daniel P. Berrange" writes: >>> On Fri, Jul 07, 2017 at 10:05:22AM +0200, Markus Armbruster wrote:

Re: [Qemu-block] [PATCH v6 1/2] bitmaps.md: Convert to rST; move it into 'interop' dir

viewed-by: John Snow <js...@redhat.com> --- --- docs/devel/bitmaps.md| 505 -- docs/interop/bitmaps.rst | 555 +++ A shame that git rename detection doesn't see these as the same rough contents, but

Re: [Qemu-block] [Qemu-devel] [PATCH v4 09/17] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

-by: Eric Blake <ebl...@redhat.com> Reviewed-By: John Snow <js...@redhat.com> I still think about getting Arby's when I write that line, and now I'm hungry.

Re: [Qemu-block] [Qemu-devel] [PATCH 12/17] migration: add postcopy migration of dirty bitmaps

On 07/10/2017 05:17 AM, Vladimir Sementsov-Ogievskiy wrote: Can we document this somehow? In this terminology, what happens with frozen bitmap (which in fact is like "active" for the user) on successful backup finish? It turns into a difference between current-state and what-was-backed-up?

Re: [Qemu-block] [Qemu-devel] [PATCH v4 07/17] qcow2: Switch sectors_covered_by_bitmap_cluster() to byte-based

ebl...@redhat.com> It really will be nice to not have multiple layers of scaling for bitmaps anymore. Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v4 08/17] dirty-bitmap: Set iterator start by offset, not sector

rather than sector iteration. Move the scaling to occur internally to dirty bitmap code instead, so that callers now pass in bytes. Signed-off-by: Eric Blake <ebl...@redhat.com> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v22 25/30] qmp: add x-debug-block-dirty-bitmap-sha256

On 07/10/2017 02:49 AM, Markus Armbruster wrote: > John Snow <js...@redhat.com> writes: > >> On 07/07/2017 09:53 AM, Markus Armbruster wrote: >>> Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> writes: >>> >>>> 07.07.2017 12:00, Mark

Re: [Qemu-block] [Qemu-devel] [PATCH v5 2/2] live-block-ops.txt: Rename, rewrite, and improve it

On 07/10/2017 03:53 AM, Kashyap Chamarthy wrote: > > They are useful suggestions. :-) I'm a stickler for English, and I like > to get it right. Appreciate the patience! > Hardly any such thing as "right". It's all very subjective.

Re: [Qemu-block] [Qemu-devel] [PATCH v4 06/17] dirty-bitmap: Change bdrv_dirty_bitmap_*serialize*() to take bytes

have to add more assertions that we are not truncating incorrectly, which can go away once the internal hbitmap is byte-based rather than sector-based. Signed-off-by: Eric Blake <ebl...@redhat.com> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v4 05/17] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

tor + sbc); +end = MIN(bm_sectors, sector + sbc); write_size = bdrv_dirty_bitmap_serialization_size(bitmap, sector, end - sector); assert(write_size <= s->cluster_size); @@ -1137,7 +1139,7 @@ static uint64_t *store_bitmap_data(BlockDriverState *bs, goto fail; } -if (end >= bm_size) { +if (end >= bm_sectors) { break; } Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v4 05/17] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

On 07/10/2017 05:19 PM, Eric Blake wrote: On 07/10/2017 04:09 PM, John Snow wrote: On 07/03/2017 11:10 AM, Eric Blake wrote: We are still using an internal hbitmap that tracks a size in sectors, with the granularity scaled down accordingly, because it lets us use a shortcut for our

Re: [Qemu-block] [Qemu-devel] [PATCH v5 2/2] live-block-ops.txt: Rename, rewrite, and improve it

Last time, on DRAGON BALL Q: On 07/06/2017 10:36 AM, Kashyap Chamarthy wrote: [A lot of good documentation] > + > +So, the following is the flow for `block-commit_Case-3`_ -- to convert a > +disk image chain such as this:: > + Maybe drop the "So, " "The following is the flow for 'Block Commit

Re: [Qemu-block] [Qemu-devel] [PATCH 12/17] migration: add postcopy migration of dirty bitmaps

On 07/07/2017 05:13 AM, Vladimir Sementsov-Ogievskiy wrote: > 06.07.2017 20:53, 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-Ogievski

Re: [Qemu-block] [PATCH] iscsi: use scsi_create_task()

be reaching into this structure ourselves, huh? I had to look up the iscsi source just to confirm that we /were/ doing the right thing, but now we won't have to worry about it. > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> Reviewed-by: John Snow <js...@redhat.com> This

Re: [Qemu-block] [Qemu-devel] [PATCH v4 14/17] qcow2: Switch load_bitmap_data() to byte-based iteration

;ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com> Vladimir, look good to you? --js

[Qemu-block] [PATCH v5 2/2] qemu-img: Check for backing image if specified during create

. Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 Reviewed-by: Eric Blake <ebl...@redhat.com> Signed-off-by: John Snow <js...@redhat.com> --- block.c| 96 +- qemu-img-cmds.hx | 4 +-

[Qemu-block] [PATCH v5 1/2] blockdev: move BDRV_O_NO_BACKING option forward

checking the existence of the backing file. This prevents QEMU from trying to re-open a backing file that's already in use (thanks to qcow2 locking). Signed-off-by: John Snow <js...@redhat.com> --- blockdev.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/blockd

[Qemu-block] [PATCH v5 0/2] qemu-img: Check for backing image if specified during create

generally fail to succeed because of image locking. In this case, they only warn instead of fail, but this keeps the output cleaner. Test 111 is updated to accommodate a new error message. 082, 085, 139, 156 and 158 add '-u' just to suppress warnings. John Snow (2): blockdev: move BDRV_O_NO_BACKING

Re: [Qemu-block] [PATCH v5 0/2] qemu-img: Check for backing image if specified during create

but a size was provided, which is mostly QOL. On 07/17/2017 08:34 PM, John Snow wrote: > We do not currently guarantee that QEMU will or will not open a > backing file when creating a new overlay file. Presently, QEMU will > not open that file if you provide a filesize, because it has no reaso

Re: [Qemu-block] [PATCH v5 2/2] qemu-img: Check for backing image if specified during create

On 07/18/2017 08:51 AM, Eric Blake wrote: > On 07/17/2017 07:34 PM, John Snow wrote: >> Or, rather, force the open of a backing image if one was specified >> for creation. Using a similar -unsafe option as rebase, allow qemu-img >> to ignore the backing file validation if p

Re: [Qemu-block] [Qemu-devel] [PATCH 27/29] tests/hbitmap: use ARRAY_SIZE macro

On 07/18/2017 02:10 AM, Philippe Mathieu-Daudé wrote: > Applied using the Coccinelle semantic patch scripts/coccinelle/use_osdep.cocci > > Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH v2] qemu-iotests: add a "how to" to ./README

orts of failing tests cases to qemu-de...@nongnu.org with a CC: to qemu-block@nongnu.org. + Nice! Unfortunately this does highlight how ridiculous our test number procurement process is, but at least it's documented. Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH 1/2] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

in the next commit 21b5683 in block.c, but the new code mistakenly started reporting in sectors. Fixes: https://bugzilla.redhat.com/1441460 CC: qemu-sta...@nongnu.org Signed-off-by: Eric Blake <ebl...@redhat.com> Reviewed-by: John Snow <js...@redhat.com> I must have for

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-iotests: add a "how to" to ./README

On 07/21/2017 11:51 AM, Stefan Hajnoczi wrote: On Fri, Jul 21, 2017 at 07:16:34AM -0500, Eric Blake wrote: On 07/21/2017 04:34 AM, Stefan Hajnoczi wrote: There is not much getting started documentation for qemu-iotests. This patch explains how to create a new test and covers the overall

Re: [Qemu-block] [PATCH v3] util: remove the obsolete non-blocking connect

This was posted over a month ago with two R-Bs, did it get merged or dropped? --js On 06/16/2017 04:54 AM, Mao Zhongyi wrote: From: Cao jin The non-blocking connect mechanism is obsolete, and it doesn't work well in inet connection, because it will call getaddrinfo

Re: [Qemu-block] [PATCH 1/2] iotests: Check dirty bitmap statistics in 124

active') # Prepare a cluster_size=128k backup target without a backing file. (target, _) = bitmap0.new_target() Good addition. Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

On 07/12/2017 11:18 AM, Vladimir Sementsov-Ogievskiy wrote: 30.06.2017 03:27, John Snow wrote: On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote: The function should collect statistics, about used/unused by top-level format driver space (in its .file) and allocation status (data

Re: [Qemu-block] [Qemu-devel] [RFC] block-insert-node and block-job-delete

On 07/26/2017 02:23 PM, Manos Pitsidianakis wrote: On Wed, Jul 26, 2017 at 04:12:21PM +0100, Stefan Hajnoczi wrote: On Wed, Jul 26, 2017 at 05:19:24PM +0300, Manos Pitsidianakis wrote: This proposal follows a discussion we had with Kevin and Stefan on filter node management. With block

Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

On 07/25/2017 05:37 PM, Eric Blake wrote: On 07/25/2017 04:28 PM, John Snow wrote: On 07/21/2017 02:32 PM, Eric Blake wrote: We've been documenting the value in bytes since its introduction in commit b9a9b3a4 (v1.3), where it was actually reported in bytes. Commit e4654d2 (v2.0

Re: [Qemu-block] [Qemu-devel] [PATCH v3 04/12] tests: Pass literal format strings directly to qmp_FOO()

> Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com> Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH] ide: check BlockBackend object in ide_cancel_dma_sync

On 07/14/2017 06:00 AM, P J P wrote: > From: Prasad J Pandit > > When cancelling pending DMA requests in ide_cancel_dma_sync, > the s->blk object could be null, leading to a null dereference. > Add check to avoid it. > > Reported-by: Chensongnian

Re: [Qemu-block] [Qemu-devel] [PATCH v4 15/17] qcow2: Switch store_bitmap_data() to byte-based iteration

;ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com> Vladimir, yea/nay? --js

Re: [Qemu-block] [Qemu-devel] [PATCH v4 17/17] dirty-bitmap: Convert internal hbitmap size/granularity

On 07/03/2017 11:10 AM, Eric Blake wrote: > Now that all callers are using byte-based interfaces, there's no > reason for our internal hbitmap to remain with sector-based > granularity. It also simplifies our internal scaling, since we > already know that hbitmap widens requests out to

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

On 07/12/2017 01:00 PM, Max Reitz wrote: > On 2017-07-12 16:56, Kevin Wolf wrote: >> Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: >>> On 05/17/2017 07:38 AM, Max Reitz wrote: >>> >>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 >>> >>> Or, rather,

Re: [Qemu-block] [Qemu-devel] [PATCH v4 12/17] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

ny > sub-sector requests. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > Reviewed-by: John Snow <js...@redhat.com>

Re: [Qemu-block] [Qemu-devel] [PATCH 0/3] AHCI: re-privatize ahci headers

On 06/23/2017 06:09 PM, John Snow wrote: > As reported by Philippe Mathieu-Daudé, including AHCI headers can > quickly pull in more dependencies than is sane. To remedy this, > split the AHCI headers into public and private areas as best as we > can and move the private information

Re: [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

On 06/29/2017 08:45 PM, Eric Blake wrote: > On 06/29/2017 07:27 PM, John Snow wrote: >> >> >> On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote: >>> The function should collect statistics, about used/unused by top-level >>> format driver spa

Re: [Qemu-block] [Qemu-devel] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

On 06/29/2017 02:59 AM, Vladimir Sementsov-Ogievskiy wrote: > 29.06.2017 03:15, John Snow wrote: >> >> Alright, let me see if I have this straight... >> >> used-data: Normal data. We are standing on terra-firma. >> used-zero: Data that is defined to b

Re: [Qemu-block] [Qemu-devel] [PATCH v3 00/11] make dirty-bitmap byte-based

On 06/29/2017 11:11 AM, Eric Blake wrote: > On 06/29/2017 03:28 AM, Vladimir Sementsov-Ogievskiy wrote: >> Hi! >> >> Can we apply my "[PATCH v22 00/30] qcow2: persistent dirty bitmaps" >> first? It was already near to the victory a week ago, but I had to >> rebase it on new Paolo's patches. > >

Re: [Qemu-block] [Qemu-devel] [PATCH v22 00/30] qcow2: persistent dirty bitmaps

On 06/28/2017 08:05 AM, Vladimir Sementsov-Ogievskiy wrote: > Hi all! > > There is a new update of qcow2-bitmap series - v22. > > web: > https://src.openvz.org/users/vsementsov/repos/qemu/browse?at=qcow2-bitmap-v22 > git: https://src.openvz.org/scm/~vsementsov/qemu.git (tag qcow2-bitmap-v22)

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/2] bitmaps.md: Convert to rST; move it into 'interop' dir

> Then, make a couple of small syntactical adjustments. While at it, > reword a statement to avoid ambiguity. Addressing the feedback from > this thread: > > https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg05428.html > > Signed-off-by: Kashyap Chamarthy <kch

Re: [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote: > The function should collect statistics, about used/unused by top-level > format driver space (in its .file) and allocation status > (data/zero/discarded/after-eof) of corresponding areas in this .file. > > Signed-off-by: Vladimir

Re: [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

On 06/28/2017 11:59 AM, Vladimir Sementsov-Ogievskiy wrote: > 27.06.2017 02:19, John Snow wrote: >> >> On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote: >>> The function should collect statistics, about used/unused by top-level >>> format driver sp

Re: [Qemu-block] [Qemu-devel] [PATCH v22 06/30] block/dirty-bitmap: add deserialize_ones func

On 06/29/2017 10:01 PM, Eric Blake wrote: > On 06/29/2017 08:55 PM, Eric Blake wrote: >> On 06/28/2017 07:05 AM, Vladimir Sementsov-Ogievskiy wrote: >>> Add bdrv_dirty_bitmap_deserialize_ones() function, which is needed for >>> qcow2 bitmap loading, to handle unallocated bitmap parts, marked as

Re: [Qemu-block] [PATCH v22 19/30] qcow2: add persistent dirty bitmaps support

On 06/30/2017 01:47 PM, Eric Blake wrote: > On 06/29/2017 09:23 PM, Max Reitz wrote: >> On 2017-06-30 04:18, Eric Blake wrote: >>> On 06/28/2017 07:05 AM, Vladimir Sementsov-Ogievskiy wrote: Store persistent dirty bitmaps in qcow2 image. Signed-off-by: Vladimir Sementsov-Ogievskiy

<    6   7   8   9   10   11   12   13   14   15   >