> -----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. Paul > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
