Am 25.09.2020 um 15:42 hat Stefan Hajnoczi geschrieben: > Make it possible to specify the iothread where the export will run. > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > --- > Note the x-blockdev-set-iothread QMP command can be used to do the same, > but not from the command-line. And it requires sending an additional > command. > > In the long run vhost-user-blk will support per-virtqueue iothread > mappings. But for now a single iothread makes sense and most other > transports will just use one iothread anyway. > --- > qapi/block-export.json | 4 ++++ > block/export/export.c | 26 +++++++++++++++++++++++++- > 2 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/qapi/block-export.json b/qapi/block-export.json > index 87ac5117cd..eba6f6eae9 100644 > --- a/qapi/block-export.json > +++ b/qapi/block-export.json > @@ -219,11 +219,15 @@ > # export before completion is signalled. (since: 5.2; > # default: false) > # > +# @iothread: The name of the iothread object where the export will run. The > +# default is the main loop thread. (since: 5.2)
NBD exports currently switch automatically to a different AioContext if another user (usually a guest device using the same node) tries to change the AioContext. I believe this is also the most useful mode in the context of the system emulator. I can see the need for an iothread option in qemu-storage-daemon where usually nobody else will move the node into a different AioContext. But we need to define the semantics more precisely and specify what happens if another user wants to change the AioContext later. Currently, the NBD export will allow this and just switch the AioContext - after this patch, ignoring what the user set explicitly with this new option. I see two options to handle this more consistently: 1. If @iothread is set, move the block node into the requested AioContext, and if that fails, block-export-add fails. Other users of the node will be denied to change the AioContext while the export is active. If @iothread is not given, it behaves like today: Use whatever AioContext the node is currently in and switch whenever another user requests it. 2. Add a bool option @fixed-iothread that determines whether other users can change the AioContext while the export is active. Giving an @iothread and fixed-iothread == true means that we'll enforce the given AioContext during the whole lifetime of the export. With fixed-iothread == false it means that we try to move the block node to the requested iothread if possible (but we won't fail if it isn't possible) and will follow any other user switching the AioContext of the node. Not giving @iothread means that we start with the current AioContext of the node, and @fixed-iothread then means the same as before. Does this make sense to you? Kevin
