On Fri, May 19, 2017 at 09:30:10AM +0100, Daniel P. Berrange wrote: > On Fri, May 19, 2017 at 09:25:38AM +0100, Daniel P. Berrange wrote: > > On Fri, May 19, 2017 at 02:43:27PM +0800, Peter Xu wrote: > > > We don't really have a return path for the other types yet. Let's check > > > this when .get_return_path() is called. > > > > > > For this, we introduce a new feature bit, and set it up only for socket > > > typed IO channels. > > > > > > This will help detect earlier failure for postcopy, e.g., logically > > > speaking postcopy cannot work with "exec:". Before this patch, when we > > > try to migrate with "migrate -d exec:cat>out", we'll hang the system. > > > With this patch, we'll get: > > > > > > (qemu) migrate -d exec:cat>out > > > Unable to open return-path for postcopy > > > > This is wrong - post-copy migration *can* work with exec: - it just entirely > > depends on what command you are running. Your example ran a command which is > > unidirectional, but if you ran 'exec:socat ...' you would have a fully > > bidirectional channel. Actually the channel is always bi-directional, but > > 'cat' simply won't ever send data back to QEMU. > > > > If QEMU hangs when the other end doesn't send data back, that actually seems > > like a potentially serious bug in migration code. Even if using the normal > > 'tcp' migration protocol, if the target QEMU server hangs and fails to > > send data to QEMU on the return path, the source QEMU must never hang. > > BTW, if you want to simplify the code in this area at all, then arguably > we should get rid of the "get_return_path" helper method entirely. We're > not actually opening any new connections - we're just creating a second > QEMUFile that uses the same underlying QIOChannel object. All we would > need is for the QEMUFile to have a separate 'buf' field management in > QEMUFile for the read & write directions. Then all the code would be > able to just use the single QEMUFile for read & write getting rid of this > concept of "opening a return path" which doens't actually do anything at > the underlying data transport level.
Makes sense. Noted. Thanks, -- Peter Xu