[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] question about migration


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Wen Congyang <wency@xxxxxxxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Mon, 4 Jan 2016 10:28:52 +0000
  • Accept-language: en-GB, en-US
  • Cc: xen devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 04 Jan 2016 10:29:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHRPfN4BNqTgIOlF0iaF/CVqxvA3J7aAqeAgADckYCABusCAIAJavTA
  • Thread-topic: [Xen-devel] question about migration

> -----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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.