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

Re: [Xen-devel] disk io request structures

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] disk io request structures
From: Paresh Nakhe <paresh.nakhe@xxxxxxxxx>
Date: Thu, 3 Feb 2011 11:15:13 +0530
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 Feb 2011 21:46:23 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bv7Y2dn9xpqYd5dxsS6C1N5oDK92XpL1W8Vxt6d9dcs=; b=l32jNfZM4iMlSt9bJo4/pn/KL5zGez8ADFtvNzKNsTypT+fnYnJESOUvXwR4kA9iJ1 asr8GO1r+g0DgW0zVFsmIO67XY8UTk3Ve5MDGeP3Htpu2/bG9bVr83ulZMa+arksua13 zu1TUSgbUqK8p3RoTekiC0FjaQxoSakzhq8H4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=HKSwLQqOw5J74bH6D41Sml8aZcAfdPjOMHpIJbNPIHBmx+9CoC9XMrhOBr+wzQnW26 KXhCggPhB1K4KQDzhFPQtvLJQvcz/o/wGBnda7i9Jqkq13dXfacQexVLAkWhc0uJ4N7d NhBeouwHN6+UJu5lb4FYFNPGoY53pUImlN8+I=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01C55138@trantor>
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>
References: <AANLkTinu_28Tp1kVtKrNJ9X_V5Ruh9C-oaZDkVkU0opa@xxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01C55138@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
That was a really nice explanation. blkif_request_segment seems to be serving the same purpose which bio structure serves in native machines. (Plz correct me if i am wrong)

In your example, we are reading sectors 123-134. Is it necessary that sectors be contiguous? Also the pages to which these are mapped are shown as contiguous.
Is this always the case?

I haven't understood the concept of scatter gather request segments clearly. Does this concept have anything do something with the question stated  above?

Paresh

On Thu, Feb 3, 2011 at 5:45 AM, James Harper <james.harper@xxxxxxxxxxxxxxxx> wrote:
> Hi,
> Following is the structure of an IO request which is inserted in the
shared IO
> ring.
>
> include/xen/interface/io/blkif.h
>
> struct blkif_request {
>     uint8_t        operation;    /* BLKIF_OP_???
*/
>     uint8_t        nr_segments;  /* number of segments
*/
>     blkif_vdev_t   handle;       /* only for read/write requests
*/
>     uint64_t       id;           /* private guest value, echoed in
resp  */
>     blkif_sector_t sector_number;/* start sector idx on disk (r/w
only)  */
>     struct blkif_request_segment {
>         grant_ref_t gref;        /* reference to I/O buffer frame
*/
>         /* @first_sect: first sector in frame to transfer (inclusive).
*/
>         /* @last_sect: last sector in frame to transfer (inclusive).
*/
>         uint8_t     first_sect, last_sect;
>     } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> };
>
> Sorry, if my questions seem obvious or trivial. I am a newbie in xen
> development. Right now, me and my group are trying to understand the
disk io
> mechanism in XEN. We intend to modify the existing system. We expect
better
> performance after this modification.
>
> So, in the above structure,
>  1. what is a "segment" referred in the structure.
>  2. Why is there an array of blkif_request_segment (why not a single
> instance). What is it's purpose?
>  3. In the structure blkif_request_segment, are the first_sect and
last_sect
> physical sector numbers
>

Each entry on the ring contains the details of the operation. Each
operation is going to be either a read from memory or a write to memory.
The ring entry contains a list of memory pages that are granted to Dom0.

The first_sect and last_sect are worked out by thinking of each page as
holding 8 sectors (page size is 4096 bytes, sectors are 512 bytes).
first_sect and last_sect refer to the sector number offset inside that
frame, so if the address of your buffer was offset 0 then first_sect
would be 0, if it was offset 512 then first_sect would be 1, etc. Your
buffer obviously has to be aligned to a 512 byte boundary (which is a
pain for Windows!).

Probably the best way to describe it is an example. Suppose you want to
read sectors 123-134 (11 sectors) into virtual memory starting at
address 0x12345600 (length 11 * 512 = 5632). You would do the following:

1. Get the pfn's of the memory. Eg virtual address 0x12345600-0x12346BFF
might map to pages 0x4444 and 0x5555
2. Get a grant ref and grant access to those pfn's. Your grant refs
might be 123 and 456
3. Set the members of the struct as follow:
  . operation = read
  . nr_segments = 2 (2 pages)
  . sector_number = 123
  . handle = I forget what this is for...
  . id = your own id for you to track this request when you get the
response back
  . seg[0].gref = 123
  . seg[0].first_sect = 3 (offset 0x600 in frame)
  . seg[0].last_sect = 7
  . seg[1].gref = 456
  . seg[1].first_sect = 0
  . seg[1].last_sect = 5

Please excuse any arithmetic errors I might have made above, but the
logic should be right.

James



--
What I have is not a dream, because I will make it a reality.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>