> -----Original Message----- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 16 October 2014 11:10 > To: Paul Durrant; Peter Maydell > Cc: QEMU Developers; xen-de...@lists.xenproject.org; Stefano Stabellini; > Michael Tokarev; Stefan Hajnoczi; Stefan Weil; Olaf Hering; Gerd Hoffmann; > Alexey Kardashevskiy; Alexander Graf > Subject: Re: [PATCH v3 2/2] Xen: Use the ioreq-server API when available > > Il 16/10/2014 10:25, Paul Durrant ha scritto: > >>> +static void xen_hvm_pre_save(void *opaque) > >>> +{ > >>> + XenIOState *state = opaque; > >>> + > >>> + /* Stop servicing emulation requests */ > >>> + xen_set_ioreq_server_state(xen_xc, xen_domid, state->ioservid, > 0); > >>> + xen_destroy_ioreq_server(xen_xc, xen_domid, state->ioservid); > >>> +} > >> > >> Is the new use of vmstate_register() really necessary? > >> Usually the state you're saving corresponds to some QOM > >> device whose vmsd field you can use instead. > > > > In this case, it seems like a job for a vmstate change handler. > > > > I looked at that but it did not seem to give me the right semantic, > > whereas the pre-save callback gave me exactly the right semantic. > > What exactly is the right semantics? Note that save _can_ fail, so you > need the ability to roll back to the source machine. I think this is > missing from your patch, and there is no post_save hook that you can use. >
I need something that will be called prior to the VM memory image being saved, but if save can fail I will also need something to be called if that occurs too. Paul > Paolo