> -----Original Message----- > From: Andrew Cooper > Sent: 12 December 2016 16:27 > To: Paul Durrant <paul.durr...@citrix.com>; Boris Ostrovsky > <boris.ostrov...@oracle.com>; Jan Beulich <jbeul...@suse.com>; Juergen > Gross <jgr...@suse.com>; xen-devel <xen-devel@lists.xen.org> > Cc: zhangchen.f...@cn.fujitsu.com > Subject: Re: ioreq server regression > > On 12/12/16 16:22, Paul Durrant wrote: > >> -----Original Message----- > >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > >> Sent: 12 December 2016 16:02 > >> To: Paul Durrant <paul.durr...@citrix.com>; Jan Beulich > >> <jbeul...@suse.com>; Andrew Cooper <andrew.coop...@citrix.com>; > >> Juergen Gross <jgr...@suse.com>; xen-devel <xen-devel@lists.xen.org> > >> Cc: zhangchen.f...@cn.fujitsu.com > >> Subject: ioreq server regression > >> > >> Looks like commit e7dabe59c ("x86/hvm: don't unconditionally create a > >> default ioreq server") breaks restore for HVM guests. > >> > >> I see "qemu: hardware error: Invalid ioreq type 0x53" in qemu log. > >> > > Damn, yes that will be the case when migrating with legacy QEMU... we're > going to need another flag that's set on the domain by the restore code so > that the default server also gets created on restore. > > I don't understand why the existing code doesn't suffice. A domain > being restored is conceptually no different from one which is still > being constructed. > > The creation_finished flag should still be clear at this point during > restore.
That's the problem... The creation flag is clear so reading the HVM params does not instantiate the default ioreq server in the target domain. Paul > Is it perhaps something else doing a pause/unpause on the > domain before qemu starts up? The creation_finished flag should only be > set at the first point the refcount goes to zero, not the first unpause > hypercall. > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
