From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritu kaur Subject: Re: modifying drivers Date: Fri, 19 Feb 2010 18:15:56 -0800 Message-ID: <29b32d341002191815t2b06944s8670721e7325d8d8@mail.gmail.com> References: <29b32d341002180827v7cd5f219u767f97554fdf4c58@mail.gmail.com> <1266511171.10261.2027.camel@zakaz.uk.xensource.com> <29b32d341002181603v4664b3ebn8b8a89b88f2ab63c@mail.gmail.com> <1266570469.10261.6982.camel@zakaz.uk.xensource.com> <29b32d341002190912n50cf83a5l40dacd2d331fac2e@mail.gmail.com> <1266600267.11737.545.camel@zakaz.uk.xensource.com> <29b32d341002191430q4261fd32y8b6834125c0ca04@mail.gmail.com> <4B7F2B34.6040608@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0843502211==" Return-path: In-Reply-To: <4B7F2B34.6040608@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org --===============0843502211== Content-Type: multipart/alternative; boundary=000e0cd1120cc3b7a0047ffec7e4 --000e0cd1120cc3b7a0047ffec7e4 Content-Type: text/plain; charset=ISO-8859-1 Hi Jeremy, Thanks for clarification, however, what I dont understand is this(I have read documents and looked into driver code). Both netfront and netback registers with xenbus and monitors "vif" interface. From netback point of view I clearly understand its communication and other stuff as I see vif: being created in dom0. However, when I look into domU, I do not see any vif interface created(looked with ifconfig, ifconfig -a commands) is it hidden from the user? In domU, I just see "eth*" interfaces created. how does eth* interfaces interact with netfront? I looked under lib/modules/linux*/... for any pseudo drivers which might interact with eth*, didn't get any answers. I am completely confused. By the way I am using Debian etch 4.0 as a domU. Jeremy/Ian, have any inputs on ioctl support? Thanks On Fri, Feb 19, 2010 at 4:22 PM, Jeremy Fitzhardinge wrote: > On 02/19/2010 02:30 PM, Ritu kaur wrote: > >> Thanks for the clarification. In our team meeting we decided to drop >> netback changes to support exclusive access and go with xe command line or >> xencenter way to do it(We are using Citrix Xenserver). Had couple of >> follow-up questions related to Xen. >> >> 1.Is it correct that netfront driver(or any *front driver) has to be >> explicitly integrated or compiled in the guest OS? the reason I ask this is, >> > > An HVM domain can be completely unmodified, but it will be using emulated > hardware devices with its normal drivers. > > a. In the documents I have read, it mentions guest OS can run without any >> modification, however, if above is true we have to make sure guest OS we use >> are compiled with the relevant *front drivers. >> > > An HVM domain can use PV drivers to optimise its IO path by bypassing the > emulated devices and talking directly to the backends. PV domains always > use PV drivers (but they've already been modified). > > b. we had done some changes to netback and netfront(as mentioned in the >> previous email), when compiling kernel for dom0 it includes both netfront >> and netback and assumed via some mechanism this netfront driver would be >> integrated/installed into guest domains when they are installed. >> > > No. A dom0 kernel doesn't have much use for frontends. They're usually > present because a given kernel can run in either the dom0 or domU roles. > > 2. Any front or back driver communication is via xenbus only? >> > > Xenbus is used to pass small amounts of control/status/config information > between front and backends. Bulk data transfer is usually handled with > shared pages containing ring buffers, and event channels for event > signalling. > > 3. Supporting ioctl calls. Our driver has ioctl support to read/write >> hardware registers and one solution was to use pci passthrough mechanism, >> however, it binds the NIC to a specific domU and we do not want that. We >> would like to have multiple users access to hw registers(mainly stats and >> other stuff) via guest domains and be able to access them simultaneously. >> For this, we decided to go with the mechanism of shared memory/event channel >> similar to front and back drivers. Can you please provide some inputs on >> this? >> > > It's hard to make any suggestions without knowing what your hardware is or > what the use-cases are for these ioctls. Are you saying that you want to > give multiple domUs direct unrestricted (read only?) access to the same set > of registers? What kind of stats? Do guests need to read them at a very > high rate, or could they fetch accumulated results at a lower rate? > > J > --000e0cd1120cc3b7a0047ffec7e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jeremy,

Thanks for clarification, however, what I dont understan= d is this(I have read documents and looked into driver code). Both netfront= and netback registers with xenbus and monitors "vif" interface. = >>From netback point of view I clearly understand its communication and other= stuff as I see vif<domid>:<intf-id> being created in dom0. How= ever, when I look into domU, I do not see any vif interface created(looked = with ifconfig, ifconfig -a commands) is it hidden from the user? In domU, I= just see "eth*" interfaces created. how does eth* interfaces int= eract with netfront? I looked under lib/modules/linux*/... for any pseudo d= rivers which might interact with eth*, didn't get any answers. I am com= pletely confused. By the way I am using Debian etch 4.0 as a domU.

Jeremy/Ian, have any inputs on ioctl support?

Thanks


=
On Fri, Feb 19, 2010 at 4:22 PM, Jeremy Fitzhard= inge <jeremy@goop.o= rg> wrote:
On 02/19/2010 02:30 PM, Ritu kaur wrote:
Thanks for the clarification. In our team meeting we decided to drop netbac= k changes to support exclusive access and go with xe command line or xencen= ter way to do it(We are using Citrix Xenserver). Had couple of follow-up qu= estions related to Xen.

1.Is it correct that netfront driver(or any *front driver) has to be explic= itly integrated or compiled in the guest OS? the reason I ask this is,

An HVM domain can be completely unmodified, but it will be using emulated h= ardware devices with its normal drivers.

a. In the documents I have read, it mentions guest OS can run without any m= odification, however, if above is true we have to make sure guest OS we use= are compiled with the relevant *front drivers.

An HVM domain can use PV drivers to optimise its IO path by bypassing the e= mulated devices and talking directly to the backends. =A0PV domains always = use PV drivers (but they've already been modified).

b. we had done some changes to netback and netfront(as mentioned in the pre= vious email), when compiling kernel for dom0 it includes both netfront and = netback and assumed via some mechanism this netfront driver would be integr= ated/installed into guest domains when they are installed.

No. =A0A dom0 kernel doesn't have much use for frontends. =A0They'r= e usually present because a given kernel can run in either the dom0 or domU= roles.

2. Any front or back driver communication is via xenbus only?

Xenbus is used to pass small amounts of control/status/config information b= etween front and backends. =A0Bulk data transfer is usually handled with sh= ared pages containing ring buffers, and event channels for event signalling= .

3. Supporting ioctl calls. Our driver has ioctl support to read/write hardw= are registers and one solution was to use pci passthrough mechanism, howeve= r, it binds the NIC to a specific domU and we do not want that. We would li= ke to have multiple users access to hw registers(mainly stats and other stu= ff) via guest domains and be able to access them simultaneously. For this, = we decided to go with the mechanism of shared memory/event channel similar = to front and back drivers. =A0Can you please provide some inputs on this?

It's hard to make any suggestions without knowing what your hardware is= or what the use-cases are for these ioctls. =A0Are you saying that you wan= t to give multiple domUs direct unrestricted (read only?) access to the sam= e set of registers? =A0What kind of stats? =A0Do guests need to read them a= t a very high rate, or could they fetch accumulated results at a lower rate= ?

=A0 =A0J

--000e0cd1120cc3b7a0047ffec7e4-- --===============0843502211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0843502211==--