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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, May 12, 2016 at 02:03:31PM +0100, Paul Durrant wrote:
> > -----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?
> 

Our general support statement is to support N->N+1 migration, so it is
not really critical for me. On the other hand, if the fix is not overly
complex, it would be nice to have for 4.7.

Note that the fix will need to be in upstream QEMU first before it can
be cherry-picked to our tree, so there is risk that it might just be
blocked on QEMU side (I haven't checked their schedule). So I wouldn't
really block xen release just for that.

If for some reason (either you don't have time or the patch is blocked
on QEMU side) the fix doesn't make 4.7.0 I would suggest QEMU maintainer
to backport to 4.7.1 etc.

Wei.

>   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