Re: [Xen-devel] xen-blkfront: simplify resume?

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 24/03/2011 09:31, "Daniel Stodden" <daniel.stodden@xxxxxxxxxx> wrote:

> Dear xen-devel.
> 
> I think the blkif_recover (blkfront's transparent VM resume) stuff looks
> quite overcomplicated.
> 
> We copy the ring message to a shadow request allocated during submit, a
> process involving some none-obvious-looking get_id_from_freelist()
> subroutine to obtain a vector slot, and a memcpy.
> 
> When receiving a resume callback from xenstore, we memcpy the entire
> shadow vector, reset the original one to zero, then reallocate the
> thereby freed shadow entries and not only copy the message on the ring,
> but the shadow back into the shadow vector just freed to keep stuff
> consistent. Hmmm.
> 
> I wonder, should we just take the pending request and push it back onto
> the request_queue (with a blk_requeue_request)?

Are you suggesting to get rid of the shadow state? It is needed, because
in-flight requests can be overwritten by out-of-order responses written into
the shared ring by the backend driver.

 -- Keir

> Different from the present code, this should also help preserve original
> submit order if done right. (Don't panic, not like it matters a lot
> anymore since the block barrier flags are gone.)
> 
> If we want to keep the shadow copy, let's do so with a prep_rq_fn. It
> gets called before the request gets pulled off the queue. Looks nicer,
> and one can arrange things so it only gets called once.
> 
> Counter opinions?
> 
> Thanks,
> Daniel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel