Re: [Xen-devel] question about io path in the front/backend

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> In the phy:device mode, dom0 and domU share the page filled with the I/O
> request, which is transfered between frontend and backend, is it ?

Whatever the device mode, if the PV drivers are in use then the domU grants 
dom0 the right to share the pages to be filled.  dom0 then maps these pages, 
fills them with data, then unmaps them and notifies the domU.

> and 
> you know, in the native linux, there are buffer and cache ,such as bio
> or something , which is shared in I/Opath ,say by FS and Block Driver,
> is it? and what about the cache or buffer in the front/backend mode in
> xen, say phy:device mode,does front/backend share some cache or buffer
> ,or does front/backend share no cache or buffer at all?

The domU maintains its own caches and dom0 just supplies it with data.  dom0 
doesn't cache stuff on behalf of the domU - in fact, the block backend driver 
bypasses the page cache in dom0 entirely and transfers data directly into the 
domU's memory.

> and what about 
> the granttable's function? does granttable (or shared page filled with
> I/Oreqest or I/O data) function as the cache or buffer in the native
> linux I/O path?

The pages which the frontend domain granted to the backend are the sources or 
destinations of the IO data.  They are not part of the page cache in dom0.  
dom0 maps them, then creates BIOs pointing to them and submits these to the 
block layer.  dom0's block layer gets the data from the device and puts it 
into this mapped domU memory (or takes data from memory and puts it on disk).

In the domU, the pages form part of that domain's own private page cache but 
dom0 does not know about this.

> or does the shared page between the front/backend act 
> only as transferring the data and I/Orequest , or does it have a cache
> or buffer function as the cache or buffer such as bio in the native linux?

The shared ring page between front and back ends is just used for transferring 
details of requests (like "get this data in memory, and put it here on 
disk").  i.e. The shared ring contains request metadata.  The pages that are 
temporarily mapped from the domU into dom0 contain the actual data.

Cheers,
Mark

>
> Thanks in advance
>
> Mark Williamson åé:
> >>   I have read some documents and wiki about split driver in xen,and I am
> >> confused about the I/O path ,in which a sys_read() pass through the domU
> >> and dom0,does sys_read() in the domU pass through vfs and ,say ,ext3fs
> >> in domU,and insert request into the requeest_queue of the
> >> frontend-driver,is it right?
> >
> > Sounds like you have the right idea.  Requests get queued with the
> > frontend driver in terms of Linux structures.  IO requests to satisfy
> > these are then placed into the shared memory ring so that the backend can
> > find out what we're asking for.
> >
> >>   and then ,say domU sets up with a *.img file in the dom0, then what
> >> does frontend and backend driver do?
> >> does frontend transmit the request to the backend ,is it right?
> >
> > Yes, the frontend does this by putting requests into the shared memory
> > ringbuffer which is also accessible by the backend.  The frontend then
> > sends and event to the backend; this causes an interrupt in the backend
> > so that it knows it must check the shared memory.
> >
> >>   and then what does backend driver do ? does backend transfer the
> >> request to the phyiscal driver in the dom0 ,is it right?
> >
> > Yes.  The backend responds to the interrupt by checking the shared memory
> > for new requests, then it maps parts of the domUs memory so that dom0
> > will be able to write data into it.  Then it submits requests to the
> > Linux block IO subsystem to fill that memory with data.  The Linux block
> > IO system eventually sends these requests to the device driver, to do the
> > IO directly into the mapped domU memory.
> >
> >>  or does backend transfer the request into some read()operation ,and
> >> submit it to the vfs and ,say,ext3fs in dom0, and do another relatively
> >> complete io path in the dom0,is it right?
> >
> > If you're just exporting a phy: device to the guest, then the block IO
> > requests go down to the block device driver for that device and are
> > serviced there.  e.g. if I export IDE driver phy:/dev/hda to my guest,
> > then the IDE driver will satisfy the IO requests directly.
> > Requests go backend -> block layer -> real device driver
> >
> > If you're using a file: device then you have to go through the filesystem
> > layer...  So the IO requests go backend -> block layer -> loopback block
> > device -> ext3 -> block layer (again) -> real device driver
> >
> > If you're using blktap then the requests take a trip via userspace before
> > getting submitted.
> >
> >>  or  if  backend  transfer the request to physical driver directly, how
> >> does the backend deal with the request's virtual address ,and how does
> >> backend manage bio buffer ,does physical driver and backend and frontend
> >> share the bio buffer in  some way, or what does xen deal with it ?
> >
> > I hope what I've said clarifies things a bit.
> >
> > Cheers,
> > Mark



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel