Date: Tue, 3 Sep 2013 07:49:30 -0600 From: "Justin T. Gibbs" <gibbs@freebsd.org> To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com> Cc: "freebsd-xen@freebsd.org" <freebsd-xen@freebsd.org> Subject: Re: blkback making assumptions about the id of the requests Message-ID: <4735C4C7-6348-401D-86BD-013099D2E247@freebsd.org> In-Reply-To: <5225AE4C.1030108@citrix.com> References: <5224D1DE.8080906@citrix.com> <D8D631B6-3DB4-4F7C-A0B0-590C7B5FA250@freebsd.org> <5225AE4C.1030108@citrix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 2013, at 3:39 AM, Roger Pau Monn=E9 <roger.pau@citrix.com> = wrote: > On 02/09/13 22:03, Justin T. Gibbs wrote: >> On Sep 2, 2013, at 11:58 AM, Roger Pau Monn=E9 <roger.pau@citrix.com> = wrote: >>=20 >>> Hello, >>>=20 >>> 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. >>>=20 >>> Roger. >>=20 >> It looks to me like the id is set in xbb_dispatch_io(). Why it is = done there >> and not earlier, I don't recall. >=20 > Sorry, I've missed to spot that the id is set there, the problem is = that > requests of type BLKIF_OP_FLUSH_DISKCACHE never reach that point, so > they end up having incorrect requests ids. I've reworded the commit > message and removed the late setting of the request id, now it is set > earlier so requests of type flush also have a valid id when writing = the > response on the ring. Makes sense. Committed. -- Justin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4735C4C7-6348-401D-86BD-013099D2E247>