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