Re: [Xen-devel] disk io request structures

[Paresh Nakhe <paresh.nakhe@xxxxxxxxx>]

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