From mboxrd@z Thu Jan 1 00:00:00 1970 From: tgh Subject: Re: question about io path in the front/backend Date: Fri, 07 Dec 2007 17:25:24 +0800 Message-ID: <47591184.2080101@sina.com.cn> References: <10EA09EFD8728347A513008B6B0DA77A02621F51@pdsmsx411.ccr.corp.intel.com> <473BEF62.2070606@sina.com.cn> <200712040258.32187.mark.williamson@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <200712040258.32187.mark.williamson@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Williamson , Tim Deegan Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org hi In the phy:device mode, dom0 and domU share the page filled with the I/O=20 request, which is transfered between frontend and backend, is it ?and=20 you know, in the native linux, there are buffer and cache ,such as bio=20 or something , which is shared in I/Opath ,say by FS and Block Driver,=20 is it? and what about the cache or buffer in the front/backend mode in=20 xen, say phy:device mode,does front/backend share some cache or buffer=20 ,or does front/backend share no cache or buffer at all? and what about=20 the granttable's function? does granttable (or shared page filled with=20 I/Oreqest or I/O data) function as the cache or buffer in the native=20 linux I/O path? or does the shared page between the front/backend act=20 only as transferring the data and I/Orequest , or does it have a cache=20 or buffer function as the cache or buffer such as bio in the native linux= ? Thanks in advance Mark Williamson =E5=86=99=E9=81=93: >> 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 do= mU >> 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? >> =20 > > Sounds like you have the right idea. Requests get queued with the fron= tend=20 > driver in terms of Linux structures. IO requests to satisfy these are = then=20 > placed into the shared memory ring so that the backend can find out wha= t=20 > we're asking for. > > =20 >> 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?=20 >> =20 > > Yes, the frontend does this by putting requests into the shared memory=20 > ringbuffer which is also accessible by the backend. The frontend then = sends=20 > and event to the backend; this causes an interrupt in the backend so th= at it=20 > knows it must check the shared memory. > > =20 >> and then what does backend driver do ? does backend transfer the >> request to the phyiscal driver in the dom0 ,is it right? >> =20 > > Yes. The backend responds to the interrupt by checking the shared memo= ry for=20 > new requests, then it maps parts of the domUs memory so that dom0 will = be=20 > able to write data into it. Then it submits requests to the Linux bloc= k IO=20 > subsystem to fill that memory with data. The Linux block IO system=20 > eventually sends these requests to the device driver, to do the IO dire= ctly=20 > into the mapped domU memory. > > =20 >> or does backend transfer the request into some read()operation ,and >> submit it to the vfs and ,say,ext3fs in dom0, and do another relativel= y >> complete io path in the dom0,is it right? >> =20 > > If you're just exporting a phy: device to the guest, then the block IO=20 > requests go down to the block device driver for that device and are ser= viced=20 > there. e.g. if I export IDE driver phy:/dev/hda to my guest, then the = IDE=20 > 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 filesyst= em=20 > layer... So the IO requests go backend -> block layer -> loopback bloc= k=20 > device -> ext3 -> block layer (again) -> real device driver > > If you're using blktap then the requests take a trip via userspace befo= re=20 > getting submitted. > > =20 >> or if backend transfer the request to physical driver directly, ho= w >> does the backend deal with the request's virtual address ,and how does >> backend manage bio buffer ,does physical driver and backend and fronte= nd >> share the bio buffer in some way, or what does xen deal with it ? >> =20 > > I hope what I've said clarifies things a bit. > > Cheers, > Mark > > =20