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

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

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


> ~Andrew
Xen-devel mailing list



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