Re: [Qemu-block] [Qemu-devel] [RFC 0/7] block: Try to use correctly typed blockdev options

On 2018-05-04 17:53, Max Reitz wrote: [...] > So if you use it the "proper" way: > > $ x86_64-softmmu/qemu-system-x86_64 -nodefaults \ > -drive if=none,driver=raw,file=blkdebug::null-co://,file.align=512 \ > -monitor stdio > QEMU 2.12.50 monitor - type 'help' for more information >

Re: [Qemu-block] [PATCH 0/2] qemu-iotests: post-QEMU 2.12 fixes for 185

On Fri, May 04, 2018 at 04:50:12PM +0100, Stefan Hajnoczi wrote: > The 185 qemu-iotests test case was in a bad state for the QEMU 2.12 release. > We fudged the expected test output to make it pass, except for > non-deterministic behavior. > > These patches get us back to pre-QEMU 2.12. Notably

Re: [Qemu-block] [PATCH 0/2] qemu-iotests: post-QEMU 2.12 fixes for 185

Oops, the comments in 185 should be updated too. Will fix in v2. Please go ahead an review the series anyway! Stefan

Re: [Qemu-block] [PATCH v2 7/8] xen_disk: use a single entry iovec

> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 04 May 2018 14:56 > To: xen-de...@lists.xenproject.org; qemu-block@nongnu.org; qemu- > de...@nongnu.org > Cc: Paul Durrant ; Stefano Stabellini > ; Anthony

Re: [Qemu-block] [PATCH 1/2] qemu-iotests: reduce chance of races in 185

04.05.2018 18:50, Stefan Hajnoczi wrote: Commit 8565c3ab537e78f3e69977ec2c609dc9417a806e ("qemu-iotests: fix 185") identified a race condition in a sub-test. Similar issues also affect the other sub-tests. If disk I/O completes quickly, it races with the QMP 'quit' command. This causes

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: return allocated size for block device with qcow2 format

> Yeah, well, then you use qemu-img check to repair it. The refcount > structure is there to know which clusters are allocated, so we should > use it when we want to know that and not assume it's broken. If the > user thinks it may be broken, they are free to run qemu-img check to check. Yea,

Re: [Qemu-block] [Qemu-devel] [RFC 0/7] block: Try to use correctly typed blockdev options

On 2018-05-03 10:16, Markus Armbruster wrote: > Max Reitz writes: > >> (Sorry, Markus, sorry, Kevin, if this series makes you angry.) > > Anger? Nah. Gallows humor :) Good! I like to make people happy wherever I can. >> The subject says it all, I think. The original

[Qemu-block] [PATCH 2/2] blockjob: do not cancel timer in resume

Currently the timer is cancelled and the block job is entered by block_job_resume(). This behavior causes drain to run extra blockjob iterations when the job was sleeping due to the ratelimit. This patch leaves the job asleep when block_job_resume() is called. Jobs can still be forcibly woken up

[Qemu-block] [PATCH 0/2] qemu-iotests: post-QEMU 2.12 fixes for 185

The 185 qemu-iotests test case was in a bad state for the QEMU 2.12 release. We fudged the expected test output to make it pass, except for non-deterministic behavior. These patches get us back to pre-QEMU 2.12. Notably the offsets reported in block job events now correspond to smaller buffer

[Qemu-block] [PATCH 1/2] qemu-iotests: reduce chance of races in 185

Commit 8565c3ab537e78f3e69977ec2c609dc9417a806e ("qemu-iotests: fix 185") identified a race condition in a sub-test. Similar issues also affect the other sub-tests. If disk I/O completes quickly, it races with the QMP 'quit' command. This causes spurious test failures because QMP events are

[Qemu-block] [PATCH v3 4/8] xen_backend: add an emulation of grant copy

Not all Xen environments support the xengnttab_grant_copy() operation. E.g. where the OS is FreeBSD or Xen is older than 4.8.0. This patch introduces an emulation of that operation using xengnttab_map_domain_grant_refs() and memcpy() for those environments. Signed-off-by: Paul Durrant

[Qemu-block] [PATCH v3 2/8] xen_disk: remove open-coded use of libxengnttab

Now that helpers are present in xen_backend, this patch removes open-coded calls to libxengnttab from the xen_disk code. This patch also fixes one whitspace error in the assignment of the XenDevOps initialise method. Signed-off-by: Paul Durrant --- Cc: Stefano

[Qemu-block] [PATCH v3 5/8] xen_disk: remove use of grant map/unmap

Now that the (native or emulated) xen_be_copy_grant_refs() helper is always available, the xen_disk code can be significantly simplified by removing direct use of grant map and unmap operations. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini

[Qemu-block] [PATCH v3 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev

Certain functions in xen_disk are called with a pointer to xendev (struct XenDevice *). They then use continer_of() to acces the surrounding blkdev (struct XenBlkDev) but then in various places use >xendev when use of the original xendev pointer is shorter to express and clearly equivalent. This

[Qemu-block] [PATCH v3 0/8] xen_disk: legacy code removal and cleanup

The grant copy operation was added to libxengnttab in Xen 4.8.0 (released nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying a significant amount of code purely to remain compatible with older versions of Xen. As can be inferred from the diff stats below, removing this

[Qemu-block] [PATCH v3 6/8] xen_backend: make the xen_feature_grant_copy flag private

There is no longer any use of this flag outside of the xen_backend code. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 2 +-

[Qemu-block] [PATCH v3 1/8] xen_backend: add grant table helpers

This patch adds grant table helper functions to the xen_backend code to localize error reporting and use of xen_domid. The patch also defers the call to xengnttab_open() until just before the initialise method in XenDevOps is invoked. This method is responsible for mapping the shared ring. No

[Qemu-block] [PATCH v3 3/8] xen: remove other open-coded use of libxengnttab

Now that helpers are available in xen_backend, use them throughout all Xen PV backends. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Greg Kurz Cc: Paolo Bonzini

[Qemu-block] [PATCH v3 7/8] xen_disk: use a single entry iovec

Since xen_disk now always copies data to and from a guest there is no need to maintain a vector entry corresponding to every page of a request. This means there is less per-request state to maintain so the ioreq structure can shrink significantly. Signed-off-by: Paul Durrant

Re: [Qemu-block] [PATCH 01/67] block: use local path for local headers

On Thu, May 03, 2018 at 10:50:20PM +0300, Michael S. Tsirkin wrote: > When pulling in headers that are in the same directory as C file (as > opposed to one in include/), we should use its relative path, without a > directory. Directory based path works more or less by accident. This commit

Re: [Qemu-block] [PATCH] nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply

04.05.2018 01:26, Eric Blake wrote: The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS where a server may have the final extent per context give a length beyond the original request, if it can easily prove that subsequent bytes have the same status, on the grounds that a client can

Re: [Qemu-block] [Qemu-devel] [PATCH 2/3] block/file-posix: File locking during creation

On 2018-05-03 08:45, Fam Zheng wrote: > On Sat, 04/28 13:03, Max Reitz wrote: >> On 2018-04-27 08:22, Fam Zheng wrote: >>> On Sat, 04/21 00:09, Max Reitz wrote: When creating a file, we should take the WRITE and RESIZE permissions. We do not need either for the creation itself, but we do

[Qemu-block] [PATCH v2 2/8] xen_disk: remove open-coded use of libxengnttab

Now that helpers are present in xen_backend, this patch removes open-coded calls to libxengnttab from the xen_disk code. This patch also fixes one whitspace error in the assignment of the XenDevOps initialise method. Signed-off-by: Paul Durrant --- Cc: Stefano

[Qemu-block] [PATCH v2 7/8] xen_disk: use a single entry iovec

Since xen_disk now always copies data to and from a guest there is no need to maintain a vector entry corresponding to every page of a request. This means there is less per-request state to maintain so the ioreq structure can shrink significantly. Signed-off-by: Paul Durrant

[Qemu-block] [PATCH v2 1/8] xen_backend: add grant table helpers

This patch adds grant table helper functions to the xen_backend code to localize error reporting and use of xen_domid. The patch also defers the call to xengnttab_open() until just before the initialise method in XenDevOps is invoked. This method is responsible for mapping the shared ring. No

[Qemu-block] [PATCH v2 4/8] xen_backend: add an emulation of grant copy

Not all Xen environments support the xengnttab_grant_copy() operation. E.g. where the OS is FreeBSD or Xen is older than 4.8.0. This patch introduces an emulation of that operation using xengnttab_map_domain_grant_refs() and memcpy() for those environments. Signed-off-by: Paul Durrant

[Qemu-block] [PATCH v2 5/8] xen_disk: remove use of grant map/unmap

Now that the (native or emulated) xen_be_copy_grant_refs() helper is always available, the xen_disk code can be significantly simplified by removing direct use of grant map and unmap operations. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini

[Qemu-block] [PATCH v2 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev

Certain functions in xen_disk are called with a pointer to xendev (struct XenDevice *). They then use continer_of() to acces the surrounding blkdev (struct XenBlkDev) but then in various places use >xendev when use of the original xendev pointer is shorter to express and clearly equivalent. This

[Qemu-block] [PATCH v2 0/8] xen_disk: legacy code removal and cleanup

The grant copy operation was added to libxengnttab in Xen 4.8.0 (released nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying a significant amount of code purely to remain compatible with older versions of Xen. As can be inferred from the diff stats below, removing this

[Qemu-block] [PATCH v2 3/8] xen: remove other open-coded use of libxengnttab

Now that helpers are available in xen_backend, use them throughout all Xen PV backends. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard Cc: Greg Kurz Cc: Paolo Bonzini

[Qemu-block] [PATCH v2 6/8] xen_backend: make the xen_feature_grant_copy flag private

There is no longer any use of this flag outside of the xen_backend code. Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard v2: - New in v2 --- hw/xen/xen_backend.c | 2 +-

Re: [Qemu-block] [PATCH] nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply

On 05/04/2018 05:40 AM, Vladimir Sementsov-Ogievskiy wrote: 04.05.2018 01:26, Eric Blake wrote: The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS where a server may have the final extent per context give a length beyond the original request, if it can easily prove that subsequent

[Qemu-block] [PULL 3/4] nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE

A missing space makes for poor error messages, and sizes can't go negative. Also, we missed diagnosing a server that sends a maximum block size less than the minimum. Fixes: 081dd1fe CC: qemu-sta...@nongnu.org Signed-off-by: Eric Blake Message-Id:

[Qemu-block] [PULL 1/4] nbd/client: fix nbd_negotiate_simple_meta_context

From: Vladimir Sementsov-Ogievskiy Initialize received variable. Otherwise, is is possible for server to answer without any contexts, but we will set context_id to something random (received_id is not initialized too) and return 1, which is wrong. To solve it, just

[Qemu-block] [PULL 2/4] migration/block-dirty-bitmap: fix memory leak in dirty_bitmap_load_bits

From: Vladimir Sementsov-Ogievskiy Release buf on error path too. Bug was introduced in b35ebdf076d697bc "migration: add postcopy migration of dirty bitmaps" with the whole function. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-Id:

[Qemu-block] [PULL 4/4] nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply

The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS where a server may have the final extent per context give a length beyond the original request, if it can easily prove that subsequent bytes have the same status, on the grounds that a client can take advantage of this information for

Re: [Qemu-block] [PATCH] qemu-img: return allocated size for block device with qcow2 format

On 2018-05-03 15:08, 叶残风 wrote: >> The whole implementation reminds me a lot of qcow2's check function, >> which basically just recalculates the refcounts.  So I'm wondering >> whether you could just count how many clusters with non-0 refcount there >> are and thus simplify the implementation

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: return allocated size for block device with qcow2 format

On 2018-05-03 15:06, 叶残风 wrote: > > Thanks for your review, Eric. > Yes, the wr_highest_offset can tell the end offset at runtime, and  > write_threshold similar to it. But in my situation, I need to know  > the allocated end without a vm running. Oh, I've just seen that your patch doesn't even