[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/2] nbd: build qemu-nbd on Windows
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 0/2] nbd: build qemu-nbd on Windows |
Date: |
Tue, 25 Aug 2020 15:55:17 +0100 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
On Mon, Aug 24, 2020 at 06:02:16PM +0100, Daniel P. Berrangé wrote:
> We are already building the NBD client and server on Windows when it is
> used via the main system emulator binaries. This demonstrates there is
> no fundamental blocker to buildig the qemu-nbd binary too.
>
>
> In testing this I used:
>
> wine qemu-nbd.exe -t -p 9000 demo.img
>
> and
>
> wine qemu-img.exe info nbd:localhost:9000
>
> In fact I tested the full matrix of native vs windows client and native
> vs windows server.
>
> I did notice that native qemu-img will sometimes hang when talking to
> the windows qemu-nbd.exe binary, and the windows qemu-img will almost
> always hang.
>
> The hang happens in the "blk_unref" call in collect_image_info_list().
> This suggests something related to the socket teardown / cleanup in
> the NBD code.
>
> While we should obviously investigate and fix that, I didn't consider
> it a blocker for enabling build of qemu-nbd.exe, since we're already
> building the same (buggy) NBD code in the system emulators on Windows.
After more debugging here's where it is getting stuck...
The main NBD client coroutine in qemu-img.exe is getting stuck in
nbd_read_eof() call where it has done qio_channel_readv() and got
QIO_CHANNEL_ERR_BLOCK. It has thus run qio_channel_yield(G_IO_IN)
and is waiting for that to return control, where upon it will exit
on EOF
Meanwhile the main qemu-img thread is in nbd_teardown_connection
having run qio_channel_shutdown(BOTH), and is now stuck forever in
BDRV_POLL_WHILE(bs, s->connection_co); waiting for the main NBD
coroutine to exit.
On native builds, we'll get G_IO_IN|G_IO_HUP in the coroutine after
calling the qio_channel_shutdown() in the main thread, and thus
the coroutine exits.
On windows builds running under Wine this doesn't seem to happen.
If I strace the wine program it does happen. IOW there's is some
kind of race condition wrt socket shutdown in QEMU when run in
Wine.
On windows builds running Windows Server 2008 r2, it appears to
work correctly. Maybe this is just luck, or maybe the bug really
is only affecting Wine.
I don't intend to investigate this hang any more though, given
that it doesn't seem to reproduce in native Windows
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|