WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] xen-blkfront: simplify resume?
From: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Date: Thu, 24 Mar 2011 02:31:01 -0700
Delivery-date: Thu, 24 Mar 2011 02:31:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix VMD
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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?

Thanks,
Daniel



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

<Prev in Thread] Current Thread [Next in Thread>