All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: live migrating hvm from 4.4 to 4.7 fails in ioreq server
Date: Thu, 12 May 2016 11:55:36 +0100	[thread overview]
Message-ID: <20160512105536.GI27070@citrix.com> (raw)
In-Reply-To: <dc719cf4471848fd91e883d576c6cfc0@AMSPEX02CL03.citrite.net>

On Wed, May 11, 2016 at 12:38:46PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > Sent: 11 May 2016 13:23
> > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > server
> > 
> > On 11/05/16 13:18, Olaf Hering wrote:
> > > Migrating a HVM guest from staging-4.4 to staging fails:
> > >
> > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > char device redirected to /dev/pts/3 (label serial0)
> > > xen: ioreq server create: Cannot allocate memory
> > > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> > >
> > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> > does not
> > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7
> > fails to
> > > configure the guest properly?
> > 
> > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.  CC'ing
> > Paul
> > who did this work.
> 
> The problem is because the new QEMU will assume that the guest was provisioned with ioreq server pages. Somehow it needs to know to behave as a 'default' ioreq server (as qemu trad would) in which case the compatibility code in the hypervisor would DTRT. I guess it would be ok to just have QEMU fall back to the old 'default' HVM param mechanism if creation of an IOREQ server fails. The only other way out would be allow Xen to 'steal' the default server's pages if it doesn't exist.
> The former obviously requires a patch to QEMU (but the compat code already exists as a compile-time option so it's probably a small-ish change) and the latter requires a patch to Xen. Which is more preferable at this stage?
> 

Please help me understand: both ways require patching latest xen.git or
qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?

Wei.

>   Paul
> 
> > 
> > ~Andrew
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

  reply	other threads:[~2016-05-12 10:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 12:18 live migrating hvm from 4.4 to 4.7 fails in ioreq server Olaf Hering
2016-05-11 12:22 ` Andrew Cooper
2016-05-11 12:30   ` Olaf Hering
2016-05-11 13:07     ` Olaf Hering
2016-05-12 10:53       ` Wei Liu
2016-05-11 12:38   ` Paul Durrant
2016-05-12 10:55     ` Wei Liu [this message]
2016-05-12 12:39       ` Paul Durrant
2016-05-12 13:01         ` Wei Liu
2016-05-12 13:03           ` Paul Durrant
2016-05-12 13:18             ` Olaf Hering
2016-05-12 14:10             ` Wei Liu
2016-05-12 14:13               ` Paul Durrant
2016-05-25 20:57                 ` Konrad Rzeszutek Wilk
2016-05-26  8:30                   ` Paul Durrant
2016-06-03 20:07                     ` Konrad Rzeszutek Wilk
2016-07-26 15:45                     ` Olaf Hering
2016-07-26 15:48                       ` Paul Durrant
2016-07-29 10:11                         ` Paul Durrant
2016-07-29 10:34                           ` Paul Durrant
2016-07-29 13:10                             ` Olaf Hering
2016-07-29 13:22                               ` Paul Durrant
2016-05-12 13:38           ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160512105536.GI27070@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.