Re: [Xen-devel] question about migration

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel