Re: question about migration

[Andrew Cooper <andrew.cooper3@citrix.com>]

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