qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 2/2] Xen: Use the ioreq-server API when avail


From: Paul Durrant
Subject: Re: [Qemu-devel] [PATCH v3 2/2] Xen: Use the ioreq-server API when available
Date: Thu, 16 Oct 2014 10:16:27 +0000

> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden
> Sent: 16 October 2014 11:10
> To: Paul Durrant; Peter Maydell
> Cc: QEMU Developers; address@hidden; 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]