| Message ID | 20221116122241.2856527-8-eesposit@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Still more coroutine and various fixes in block layer | expand |
Am 16.11.2022 um 13:22 hat Emanuele Giuseppe Esposito geschrieben: > These functions end up calling bdrv_create() implemented as generated_co_wrapper > functions. > In addition, they also happen to be always called in coroutine context, > meaning all callers are coroutine_fn. > This means that the g_c_w function will enter the qemu_in_coroutine() > case and eventually suspend (or in other words call qemu_coroutine_yield()). > Therefore we need to mark such functions coroutine_fn too. > > Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Just one remark about patch ordering: This doesn't require the g_c_w_simple patches, so wouldn't it make more sense to move the g_c_w_simple right before the first patch that actually makes use of them? Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Am 21/11/2022 um 17:01 schrieb Kevin Wolf: > Am 16.11.2022 um 13:22 hat Emanuele Giuseppe Esposito geschrieben: >> These functions end up calling bdrv_create() implemented as generated_co_wrapper >> functions. >> In addition, they also happen to be always called in coroutine context, >> meaning all callers are coroutine_fn. >> This means that the g_c_w function will enter the qemu_in_coroutine() >> case and eventually suspend (or in other words call qemu_coroutine_yield()). >> Therefore we need to mark such functions coroutine_fn too. >> >> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> > > Just one remark about patch ordering: This doesn't require the > g_c_w_simple patches, so wouldn't it make more sense to move the > g_c_w_simple right before the first patch that actually makes use of > them? I thought about it, but then I thought it was too far from bdrv_create patches. Both g_c_w_simple and this patch are needed by bdrv_create_file, so I thought if you read this one first then you wouldn't have a clue on what is the end goal. Anyways, I'll change the order. Thank you, Emanuele > > Reviewed-by: Kevin Wolf <kwolf@redhat.com> >
diff --git a/block/vmdk.c b/block/vmdk.c index 26376352b9..0c32bf2e83 100644 --- a/block/vmdk.c +++ b/block/vmdk.c @@ -2285,10 +2285,11 @@ exit: return ret; } -static int vmdk_create_extent(const char *filename, int64_t filesize, - bool flat, bool compress, bool zeroed_grain, - BlockBackend **pbb, - QemuOpts *opts, Error **errp) +static int coroutine_fn vmdk_create_extent(const char *filename, + int64_t filesize, bool flat, + bool compress, bool zeroed_grain, + BlockBackend **pbb, + QemuOpts *opts, Error **errp) { int ret; BlockBackend *blk = NULL; @@ -2366,14 +2367,14 @@ static int filename_decompose(const char *filename, char *path, char *prefix, * non-split format. * idx >= 1: get the n-th extent if in a split subformat */ -typedef BlockBackend *(*vmdk_create_extent_fn)(int64_t size, - int idx, - bool flat, - bool split, - bool compress, - bool zeroed_grain, - void *opaque, - Error **errp); +typedef BlockBackend * coroutine_fn (*vmdk_create_extent_fn)(int64_t size, + int idx, + bool flat, + bool split, + bool compress, + bool zeroed_grain, + void *opaque, + Error **errp); static void vmdk_desc_add_extent(GString *desc, const char *extent_line_fmt, @@ -2616,7 +2617,7 @@ typedef struct { QemuOpts *opts; } VMDKCreateOptsData; -static BlockBackend *vmdk_co_create_opts_cb(int64_t size, int idx, +static BlockBackend * coroutine_fn vmdk_co_create_opts_cb(int64_t size, int idx, bool flat, bool split, bool compress, bool zeroed_grain, void *opaque, Error **errp) @@ -2768,10 +2769,11 @@ exit: return ret; } -static BlockBackend *vmdk_co_create_cb(int64_t size, int idx, - bool flat, bool split, bool compress, - bool zeroed_grain, void *opaque, - Error **errp) +static BlockBackend * coroutine_fn vmdk_co_create_cb(int64_t size, int idx, + bool flat, bool split, + bool compress, + bool zeroed_grain, + void *opaque, Error **errp) { int ret; BlockDriverState *bs;
These functions end up calling bdrv_create() implemented as generated_co_wrapper functions. In addition, they also happen to be always called in coroutine context, meaning all callers are coroutine_fn. This means that the g_c_w function will enter the qemu_in_coroutine() case and eventually suspend (or in other words call qemu_coroutine_yield()). Therefore we need to mark such functions coroutine_fn too. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> --- block/vmdk.c | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)