Xen project Mailing List

On Thu, Mar 24, 2011 at 2:31 AM, 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)?

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?

A bit confused. If things were as simple as stuffing the pending reqs back
into the req_queue, why resort to shadowing the requests in the first place?
(esp, with the blk barrier flags gone)

shriram

Thanks,
Daniel

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

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