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

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