[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] block ring interface: nr_segments = 0 results in BLKIF_RSP_ERROR


  • To: "Chris Youb" <chris_youb@xxxxxxxx>
  • From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
  • Date: Thu, 24 Aug 2006 15:00:41 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 24 Aug 2006 15:01:06 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=F56l0aJgAlh7s1GF7SCohAvSEqj3yzPh+MeQm91GOz6kE7EPfh5XKMpbLrfohCkd4KpzRuuqTdfViEChTWyuwk2lsZ264SDc5xoQH1YMH4SsAs2TP9RHWMMGnILWjnMB8ryMLkxxZZpYKp6oWR/Gi15nCAX6/gm4xncPw5IPkGo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

See dispatch_rw_block_io in blkback.c:

        /* Check that number of segments is sane. */
        nseg = req->nr_segments;
        if (unlikely(nseg == 0) ||
            unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
                DPRINTK("Bad number of segments in request (%d)\n", nseg);
                goto fail_response;
        }

Why is it important that the backend report that a request for
zero-length i/o is okay?

a.

On 8/24/06, Chris Youb <chris_youb@xxxxxxxx> wrote:

I am currently developing a blkfront.c for a custom OS over Xen 3.0.2-2.
Typical I/O is working, however, I ran into an error while testing a corner
case.

On standard I/O, where  { 1 <= nr_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST
} blkif_int()'s bret->status returns BLKIF_RSP_OKAY.

Yet when { nr_segments == 0 } blkif_int's bret->status is non-zero. (Yes I
realize this is an I/O call of zero-length.)

I checked the documentation and section "8.2.2 Block ring interface" states
the following but doesn't exclude 0:

"nr_segments
     number of segments for scatter / gather IO described by this request"

1) Is it possible there is a problem w/ my front-end driver (ie does anyone
else see this behaviour)?

2) If this is back-end related, shouldn't it just return BLKIF_RSP_OKAY?


 ________________________________
Now you can have a huge leap forward in email: get the new Yahoo! Mail.


_______________________________________________
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.