On 04/01/16 10:28, Paul Durrant wrote: >> -----Original Message----- > [snip] >>> We send the I/O request to the default I/O request server, but no backing >>> DM hands it. We wil wait the I/O forever...... >> Hmm yes. This needs fixing. >> >> CC'ing Paul who did the ioreq server work. >> >> This bug is caused by the read side effects of HVM_PARAM_IOREQ_PFN. The >> migration code needs a way of being able to query whether a default >> ioreq server exists, without creating one. >> >> Can you remember what the justification for the read side effects were? >> ISTR that it was only for qemu compatibility until the ioreq server work >> got in upstream. If that was the case, can we drop the read side >> effects now and mandate that all qemus explicitly create their ioreq >> servers (even if this involves creating a default ioreq server for >> qemu-trad)? >> > Yes, you're correct that the read side-effect was the only way of keeping > compatibility with existing QEMU at the time. It would be nice to remove that > hackery but it would indeed require a patch to qemu-trad and would clearly > break compatibility with distro qemu packages built prior to my modification. > An alternative solution to avoid breaking compatibility (albeit a bit icky) > would be to turn off the side effects when HVMOP_create_ioreq_server is > handled. There should be no case where a non-default server needs to be > created in advance of a default server.
I was under the impression that qemu-trad (like libxc) was expected to exactly match. There is deliberately no facility to use a distro packaged qemu-trad in the Xen build system. CC'ing toolstack maintainers for their input. If this is indeed the case, then the former option is the better course of action. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel