Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: 12 May 2016 14:02
> To: Paul Durrant
> Cc: Wei Liu; Andrew Cooper; Olaf Hering; xen-devel@xxxxxxxxxxxxx; Anthony
> Perard; Stefano Stabellini
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
> 
> On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> > > Sent: 12 May 2016 11:56
> > > To: Paul Durrant
> > > Cc: Andrew Cooper; Olaf Hering; xen-devel@xxxxxxxxxxxxx; Wei Liu
> > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > > server
> > >
> > > On Wed, May 11, 2016 at 12:38:46PM +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> > > > > Sent: 11 May 2016 13:23
> > > > > To: Olaf Hering; xen-devel@xxxxxxxxxxxxx; 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?
> > >
> >
> > Right. We either have to make QEMU accept that a VM can't support the
> ioreq server hypercalls, or have Xen make them work for old VMs. Nothing
> has to be done to the older Xen or QEMU.
> >
> 
> OK. Thanks for the explanation.
> 
> I'm neither the QEMU maintainer nor the Xen maintainer, so I've CC'ed
> Anthony and Stefano for you.
> 
> If I were to choose, I would choose to patch QEMU to keep the hypervsior
> as simple as possible.
> 
> From a release point of view, both ways require us to put a patch
> in-tree, so it doesn't make much of a difference to me.
>

Ok. Do you regard this as a critical issue for 4.7?

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

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