Re: [Qemu-block] [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API

On Mon, 11/13 19:20, Vladimir Sementsov-Ogievskiy wrote: > Hi all. > > There are three qmp commands, needed to implement external backup API. > > Using these three commands, client may do all needed bitmap management by > hand: > > on backup start we need to do a transaction: > {disable old

Re: [Qemu-block] [Qemu-devel] [PATCH] qcow2: get rid of qcow2_backing_read1 routine

On 12/12/2017 08:40 AM, Edgar Kaziakhmedov wrote: > Since bdrv_co_preadv does all neccessary checks including s/neccessary/necessary/ > reading after the end of the backing file, avoid duplication > of verification before bdrv_co_preadv call. > > Signed-off-by: Edgar Kaziakhmedov

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API

On 12/11/2017 07:18 AM, Vladimir Sementsov-Ogievskiy wrote: > 11.12.2017 14:15, Kevin Wolf wrote: >> Am 09.12.2017 um 01:57 hat John Snow geschrieben: >>> Here's an idea of what this API might look like without revealing >>> explicit merge/split primitives. >>> >>> A new bitmap property that

Re: [Qemu-block] [Qemu-devel] [PATCH] blockjob: kick jobs on set-speed

On 12/11/2017 07:08 PM, Jeff Cody wrote: > On Mon, Dec 11, 2017 at 06:46:09PM -0500, John Snow wrote: >> If users set an unreasonably low speed (like one byte per second), the >> calculated delay may exceed many hours. While we like to punish users >> for asking for stupid things, we do also

Re: [Qemu-block] [RFC 1/1] virtio: fix IO request length in virtio SCSI/block

On 12/12/2017 16:16, Denis V. Lunev wrote: > The dark side of this patch is that we are tweaking guest visible > parameter, though this should be relatively safe as above transport > layer support is present in QEMU/host Linux for a very long time. > The patch adds configurable property for VirtIO

Re: [Qemu-block] Block Migration and CPU throttling

* Peter Lieven (p...@kamp.de) wrote: > Am 21.09.2017 um 14:36 schrieb Dr. David Alan Gilbert: > > * Peter Lieven (p...@kamp.de) wrote: > > > Am 19.09.2017 um 16:41 schrieb Dr. David Alan Gilbert: > > > > * Peter Lieven (p...@kamp.de) wrote: > > > > > Am 19.09.2017 um 16:38 schrieb Dr. David Alan

Re: [Qemu-block] [PATCH v6 09/20] parallels: Switch to .bdrv_co_block_status()

12.12.2017 19:32, Eric Blake wrote: On 12/11/2017 09:24 AM, Vladimir Sementsov-Ogievskiy wrote: On the other hand, '<< BDRV_SECTOR_BITS' only produces the same size output as the input; if the left side is 32 bits, it risks overflowing. But '* BDRV_SECTOR_SIZE' always produces a 64-bit value. 

[Qemu-block] [PATCH] qcow2: get rid of qcow2_backing_read1 routine

Since bdrv_co_preadv does all neccessary checks including reading after the end of the backing file, avoid duplication of verification before bdrv_co_preadv call. Signed-off-by: Edgar Kaziakhmedov Reviewed-by: Vladimir Sementsov-Ogievskiy

Re: [Qemu-block] [PATCH v6 09/20] parallels: Switch to .bdrv_co_block_status()

On 12/11/2017 09:24 AM, Vladimir Sementsov-Ogievskiy wrote: >> On the other hand, '<< BDRV_SECTOR_BITS' only produces the same size >> output as the input; if the left side is 32 bits, it risks overflowing. >> But '* BDRV_SECTOR_SIZE' always produces a 64-bit value.  So I've >> learned (from past

[Qemu-block] [PATCH v2 3/3] iotests: add dirty bitmap migration test

The test creates two vms (vm_a, vm_b), create dirty bitmap in the first one, do several writes to corresponding device and then migrate vm_a to vm_b with dirty bitmaps. For now, only migration through shared storage for persistent bitmaps is available, so it is tested here. Only offline variant

[Qemu-block] [PATCH v2 2/3] qcow2: handle reopening bitmaps on bdrv_invalidate_cache

Consider migration with shared storage. Persistent bitmaps are stored on bdrv_inactivate. Then, on destination process_incoming_migration_bh() calls bdrv_invalidate_cache_all() which leads to qcow2_load_autoloading_dirty_bitmaps() which fails if bitmaps are already loaded on destination start. In

[Qemu-block] [PATCH v2 0/3] fix bitmaps migration through shared storage

Hi all. This fixes bitmaps migration through shared storage. Look at 02 for details. The bug introduced in 2.10 with the whole qcow2 bitmaps feature, so qemu-stable in CC. However I doubt that someone really suffered from this. v2: John, thank you for reviewing v1. changes: add John's

[Qemu-block] [PATCH v2 1/3] qcow2-bitmap: add qcow2_reopen_bitmaps_rw_hint()

Add version of qcow2_reopen_bitmaps_rw, which do the same work but also return a hint about was header updated or not. This will be used in the following fix for bitmaps reloading after migration. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: John Snow

[Qemu-block] [RFC 1/1] virtio: fix IO request length in virtio SCSI/block

Linux guests submit IO requests no longer than PAGE_SIZE * max_seg field reported by SCSI controler. Thus typical sequential read with 1 MB size results in the following pattern of the IO from the guest: 8,16 115754 2.766095122 2071 D R 2095104 + 1008 [dd] 8,16 115755

[Qemu-block] [PATCH] block: Don't acquire AioContext in hmp_qemu_io()

Commit 15afd94a047 added code to acquire and release the AioContext in qemuio_command(). This means that the lock is taken twice now in the call path from hmp_qemu_io(). This causes BDRV_POLL_WHILE() to hang for any requests issued to nodes in a non-mainloop AioContext. Dropping the first locking

Re: [Qemu-block] [PATCH V4] pci: removed the is_express field since a uniform interface was inserted

On 12/12/2017 7:36, Yoni Bettan wrote: * according to Eduardo Habkost's commit fd3b02c8896d597dd8b9e053dec579cf0386aee1 * since all PCIEs now implement INTERFACE_PCIE_DEVICE we don't need this field anymore * Devices that where only

Re: [Qemu-block] [PATCH v4] qemu-img: Document --force-share / -U

Am 12.12.2017 um 01:51 hat Fam Zheng geschrieben: > Signed-off-by: Fam Zheng > > --- > > v4: "images". [Kevin] > > v3: Document that the option is not allowed for read-write. [Stefan] > > v2: - "code{qemu-img}". [Kashyap, Eric] > - "etc.." -> "etc.". > --- >

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API

Am 11.12.2017 um 19:40 hat John Snow geschrieben: > > > On 12/11/2017 06:15 AM, Kevin Wolf wrote: > > Am 09.12.2017 um 01:57 hat John Snow geschrieben: > >> Here's an idea of what this API might look like without revealing > >> explicit merge/split primitives. > >> > >> A new bitmap property

Re: [Qemu-block] [PATCH v4] qemu-img: Document --force-share / -U

On Tue, Dec 12, 2017 at 08:51:13AM +0800, Fam Zheng wrote: > Signed-off-by: Fam Zheng [...] > qemu-img.texi | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/qemu-img.texi b/qemu-img.texi > index fdcf120f36..d93501f94f 100644 > --- a/qemu-img.texi > +++

Re: [Qemu-block] [PATCH v2 0/2] virtio-blk: miscellaneous changes

On Mon, Dec 11, 2017 at 09:16:23AM -0600, Mark Kanda wrote: > v2: add check for maximum queue size [Stefan] > > This series is for two minor virtio-blk changes. The first patch > makes the virtio-blk queue size user configurable. The second patch > rejects logical block size > physical block

Re: [Qemu-block] [PATCH v4] qemu-img: Document --force-share / -U

On Tue, Dec 12, 2017 at 08:51:13AM +0800, Fam Zheng wrote: > Signed-off-by: Fam Zheng > > --- > > v4: "images". [Kevin] > > v3: Document that the option is not allowed for read-write. [Stefan] > > v2: - "code{qemu-img}". [Kashyap, Eric] > - "etc.." -> "etc.". > --- >