From mboxrd@z Thu Jan 1 00:00:00 1970 From: tgh Subject: Re: question about io path in the front/backend Date: Wed, 05 Dec 2007 15:19:16 +0800 Message-ID: <475650F4.1040405@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 Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Thank you for your explanation and for the phy:device and file:device,which has better performance?=20 phy:device one for its direct path ,or the other one? and I am also confused about how does the frontend I/O request remap to=20 the phyiscal device in the I/O path mode of "phy:device"? the blocks in=20 "phy:device" is continuous , or not? and in the "file:device",the blocks=20 are not continuous ,is it right? 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