[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] question about migration
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |