Re: [Xen-devel] question about migration

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: 04 January 2016 10:36
> To: Paul Durrant; Wen Congyang
> Cc: xen devel; Ian Campbell; Ian Jackson; Wei Liu
> Subject: Re: [Xen-devel] question about migration
> 
> 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.
> 

It wasn't clear but I meant that compatibility with *upstream* QEMU builds 
prior to my patch would be broken. It depends whether we care about this or not.

  Paul

> If this is indeed the case, then the former option is the better course
> of action.
> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel