From owner-freebsd-xen@FreeBSD.ORG Mon Sep 2 17:58:59 2013 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DBA04905; Mon, 2 Sep 2013 17:58:59 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 168EA26A7; Mon, 2 Sep 2013 17:58:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,1008,1367971200"; d="scan'208,223";a="8345219" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 02 Sep 2013 17:58:51 +0000 Received: from [172.16.1.30] (10.30.203.1) by LONPEX01CL02.citrite.net (10.30.203.102) with Microsoft SMTP Server id 14.2.342.4; Mon, 2 Sep 2013 18:58:49 +0100 Message-ID: <5224D1DE.8080906@citrix.com> Date: Mon, 2 Sep 2013 19:58:54 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "freebsd-xen@freebsd.org" Subject: blkback making assumptions about the id of the requests Content-Type: multipart/mixed; boundary="------------040403030603090609030105" X-Originating-IP: [10.30.203.1] Cc: "Justin T. Gibbs" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 17:58:59 -0000 --------------040403030603090609030105 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hello, While playing with driver domains using FreeBSD I've found out that blkback in FreeBSD makes assumptions about the id of a request instead of actually using the id of the request on the shared ring. This seems wrong to me, since a frontend might choose whatever ids it like for the requests (like using 100-131 instead of 0-31). The patch attached fixes it by copying the id from the request on the ring to blkback internal request structure. Roger. --------------040403030603090609030105 Content-Type: text/plain; charset="UTF-8"; x-mac-type=0; x-mac-creator=0; name="0001-xen-blkback-don-t-make-assumptions-about-request-ids.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-xen-blkback-don-t-make-assumptions-about-request-ids.pa"; filename*1="tch" >From 01c3edc4446b113ec85537bb75c56c6072c4ee49 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Mon, 2 Sep 2013 15:51:47 +0200 Subject: [PATCH] xen-blkback: don't make assumptions about request ids Blkback makes assumptions about the id of the request it received from the frontend, this patch fixes it by always honoring the id passed from the frontend instead of assuming there's an implicit order in the id of the requests. --- sys/dev/xen/blkback/blkback.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sys/dev/xen/blkback/blkback.c b/sys/dev/xen/blkback/blkback.c index 2a220c4..500b347 100644 --- a/sys/dev/xen/blkback/blkback.c +++ b/sys/dev/xen/blkback/blkback.c @@ -1239,6 +1239,7 @@ xbb_get_resources(struct xbb_softc *xbb, struct xbb_xen_reqlist **reqlist, nreq->reqlist = *reqlist; nreq->req_ring_idx = ring_idx; + nreq->id = ring_req->id; if (xbb->abi != BLKIF_PROTOCOL_NATIVE) { bcopy(ring_req, &nreq->ring_req_storage, sizeof(*ring_req)); -- 1.7.7.5 (Apple Git-26) --------------040403030603090609030105--