> -----Original Message----- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: 01 September 2017 10:27 > To: Andrew Cooper <andrew.coop...@citrix.com>; Paul Durrant > <paul.durr...@citrix.com> > Cc: xen-devel@lists.xen.org; George Dunlap <george.dun...@citrix.com>; > Ian Jackson <ian.jack...@citrix.com>; Jan Beulich <jbeul...@suse.com>; > Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; Stefano Stabellini > <sstabell...@kernel.org>; Tim (Xen.org) <t...@xen.org>; Wei Liu > <wei.l...@citrix.com> > Subject: Re: [PATCH] xen: reset creation_finished flag on soft reset > > Andrew Cooper <andrew.coop...@citrix.com> writes: > > > On 01/09/2017 10:11, Vitaly Kuznetsov wrote: > >> C/s e7dabe5 ("x86/hvm: don't unconditionally create a default ioreq > >> server") broke soft reset when QEMU traditional is being used. During > >> soft reset QEMU is relaunched and default ioreq server needs to be > >> re-created upon first HVM_PARAM_*IOREQ_* request. The flag will be > >> set back to 'true' when toolstack unpauses the domain, just like after > >> normal creation. > >> > >> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> > > > > Sorry, but nack. d->creation_finished is used for a number of things, > > one being TLB safety before the vcpus have started executing. > > > > We either need to split the variable, or rework e7dabe5 to not use this. > > > > I think that adding another flag is a bad idea, even 'creation_finished' > flag looks a bit hackish to me. Adjusting e7dabe5 is probably > better. However, while reading its blurb I don't fully understand the > change: on migration we create new domain and thus reset > creation_finished. During QEMU launch we still need to create ioreq > server. Paul, could you please elaborate a bit (e.g. what are we > guarding against, when creating ioreq server is redundant) so we can > suggest a fix for soft reset?
My memory is hazy as to the exact problem, but I think it was an issue with the COLO project. IIRC they repeatedly 'migrate' a VM but then resume the original. Without e7dabe5 the sending VM ends up with a default ioreq server after the first migration because the save code reads the HVM params that trigger its creation. I wonder whether the easiest thing to do would be to modify qemu trad to do explicit ioreq server creation? It's really not that much code-change... 20-30 lines or so. Paul > > Thanks, > > -- > Vitaly _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
