From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritu kaur Subject: Re: modifying drivers Date: Sat, 20 Feb 2010 15:10:11 -0800 Message-ID: <29b32d341002201510w2cddb8s430eeea200ca5116@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> <29b32d341002191815t2b06944s8670721e7325d8d8@mail.gmail.com> <20100220115837.GE2761@reaktio.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0446285472==" Return-path: In-Reply-To: <20100220115837.GE2761@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= , Daniel Stodden Cc: Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org --===============0446285472== Content-Type: multipart/alternative; boundary=000e0cd104f44cef980480104dd8 --000e0cd104f44cef980480104dd8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Daniel and Pasi. However, I have followup questions 1. Daniel, I looked at Debian Etch 4.0 source code available from Citrix website, couldn't find netfront specific code, could you please point me to the right one. 2. Since netfront in domU actually monitors "ethX" interface and when ethX is used for transmit(via ping or other network protocols) it invokes network_start_xmit which then uses shared memory rings to communicate to backend and uses netif_poll to check for responses. In struct netfront_info_, it has a field struct net_device *netdev, and entry points are hooked to this netdev->open =3D network_open; netdev->hard_start_xmit =3D network_start_xmit; netdev->stop =3D network_close; netdev->get_stats =3D network_get_stats; netdev->poll =3D netif_poll; netdev->set_multicast_list =3D network_set_multicast_list; netdev->uninit =3D netif_uninit; ... Since netback has similar code, I will not go into it. I looked at struct net_device, it has a function ptr called "do_ioctl" and = I wanted to know if this can be used for out ioctl need i.e 1. setup netdev->do_ioctl =3D network_ioctl 2. application invokes ioctl(eth2(associated with our intf in backend), ...= ) 3. network_ioctl is called and it does similar to xmit and recv via shared memory. is this feasible? Thanks On Sat, Feb 20, 2010 at 3:58 AM, Pasi K=E4rkk=E4inen wrote: > On Fri, Feb 19, 2010 at 06:15:56PM -0800, Ritu kaur wrote: > > Hi Jeremy, > > > > Thanks for clarification, however, what I dont understand is this(I > have > > read documents and looked into driver code). Both netfront and netba= ck > > 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 int= o > > 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 se= e > > "eth*" interfaces created. how does eth* interfaces interact with > > netfront? I looked under lib/modules/linux*/... for any pseudo drive= rs > > 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. > > > > In a PV guest, xennet (frontend) driver registers the network interface a= s > ethX. > eth0 in the PV guest corresponds to vifX.0 backend in dom0. > eth1 in the PV guest corresponds to vifX.1 backend in dom0. > (X is the domain id of the guest). > > Hopefully that clears it up. > > -- Pasi > > > Jeremy/Ian, have any inputs on ioctl support? > > > > Thanks > > > > On Fri, Feb 19, 2010 at 4:22 PM, Jeremy Fitzhardinge <[1] > jeremy@goop.org> > > 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 comma= nd > > line or xencenter way to do it(We are using Citrix Xenserver). H= ad > > couple of follow-up questions related to Xen. > > > > 1.Is it correct that netfront driver(or any *front driver) has t= o > 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 netfron= t > > driver would be integrated/installed into guest domains when the= y > 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 d= o > 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 t= he > > mechanism of shared memory/event channel similar to front and ba= ck > > drivers. Can you please provide some inputs on this? > > > > It's hard to make any suggestions without knowing what your hardwa= re > is > > or what the use-cases are for these ioctls. Are you saying that y= ou > > want to give multiple domUs direct unrestricted (read only?) acces= s > 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 > > > > References > > > > Visible links > > 1. mailto:jeremy@goop.org > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > --000e0cd104f44cef980480104dd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Daniel and Pasi. However, I have followup questions

1. Daniel= , I looked at Debian Etch 4.0 source code available from Citrix website, co= uldn't find netfront specific code, could you please point me to the ri= ght one.

2. Since netfront in domU actually monitors "ethX" interface = and when ethX is used for transmit(via ping or other network protocols) it = invokes network_start_xmit which then uses shared memory rings to communica= te to backend and uses netif_poll to check for responses. In struct netfron= t_info_, it has a field struct net_device *netdev, and entry points are hoo= ked to this

=A0=A0=A0 netdev->open=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D network_= open;
=A0=A0=A0=A0=A0=A0=A0 netdev->hard_start_xmit =3D network_start= _xmit;
=A0=A0=A0=A0=A0=A0=A0 netdev->stop=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =3D network_close;
=A0=A0=A0=A0=A0=A0=A0 netdev->get_stats=A0= =A0=A0=A0=A0=A0 =3D network_get_stats;
=A0=A0=A0=A0=A0=A0=A0 netdev->poll=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = netif_poll;
=A0=A0=A0=A0=A0=A0=A0 netdev->set_multicast_list =3D netw= ork_set_multicast_list;
=A0=A0=A0=A0=A0=A0=A0 netdev->uninit=A0=A0=A0= =A0=A0=A0=A0=A0=A0 =3D netif_uninit;
...

Since netback has simila= r code, I will not go into it.

I looked at struct net_device, it has a function ptr called "do_io= ctl" and I wanted to know if this can be used for out ioctl need i.e <= br>
1. setup netdev->do_ioctl =3D network_ioctl
2. application inv= okes ioctl(eth2(associated with our intf in backend), ...)
3. network_ioctl is called and it does similar to xmit and recv via shared = memory.

is this feasible?

Thanks


On Sat, Feb 20, 2010 at 3:58 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote= :
On Fri, Feb 19, 2010 at 06:15:56PM -0800, Ritu kaur wrote:
> =A0 =A0Hi Jeremy,
>
> =A0 =A0Thanks for clarification, however, what I dont understand is th= is(I have
> =A0 =A0read documents and looked into driver code). Both netfront and = netback
> =A0 =A0registers with xenbus and monitors "vif" interface. &= gt;From netback point of
> =A0 =A0view I clearly understand its communication and other stuff as = I see
> =A0 =A0vif<domid>:<intf-id> being created in dom0. However= , when I look into
> =A0 =A0domU, I do not see any vif interface created(looked with ifconf= ig,
> =A0 =A0ifconfig -a commands) is it hidden from the user? In domU, I ju= st see
> =A0 =A0"eth*" interfaces created. how does eth* interfaces i= nteract with
> =A0 =A0netfront? I looked under lib/modules/linux*/... for any pseudo = drivers
> =A0 =A0which might interact with eth*, didn't get any answers. I a= m completely
> =A0 =A0confused. By the way I am using Debian etch 4.0 as a domU.
>

In a PV guest, xennet (frontend) driver registers the network interfa= ce as ethX.
eth0 in the PV guest corresponds to vifX.0 backend in dom0.
eth1 in the PV guest corresponds to vifX.1 backend in dom0.
(X is the domain id of the guest).

Hopefully that clears it up.

-- Pasi

> =A0 =A0Jeremy/Ian, have any inputs on ioctl support?
>
> =A0 =A0Thanks
>
> =A0 =A0On Fri, Feb 19, 2010 at 4:22 PM, Jeremy Fitzhardinge <= [1]jeremy@goop.org>
> =A0 =A0wrote:
>
> =A0 =A0 =A0On 02/19/2010 02:30 PM, Ritu kaur wrote:
>
> =A0 =A0 =A0 =A0Thanks for the clarification. In our team meeting we de= cided to drop
> =A0 =A0 =A0 =A0netback changes to support exclusive access and go with= xe command
> =A0 =A0 =A0 =A0line or xencenter way to do it(We are using Citrix Xens= erver). Had
> =A0 =A0 =A0 =A0couple of follow-up questions related to Xen.
>
> =A0 =A0 =A0 =A01.Is it correct that netfront driver(or any *front driv= er) has to be
> =A0 =A0 =A0 =A0explicitly integrated or compiled in the guest OS? the = reason I ask
> =A0 =A0 =A0 =A0this is,
>
> =A0 =A0 =A0An HVM domain can be completely unmodified, but it will be = using
> =A0 =A0 =A0emulated hardware devices with its normal drivers.
>
> =A0 =A0 =A0 =A0a. In the documents I have read, it mentions guest OS c= an run without
> =A0 =A0 =A0 =A0any modification, however, if above is true we have to = make sure guest
> =A0 =A0 =A0 =A0OS we use are compiled with the relevant *front drivers= .
>
> =A0 =A0 =A0An HVM domain can use PV drivers to optimise its IO path by= bypassing
> =A0 =A0 =A0the emulated devices and talking directly to the backends. = =A0PV domains
> =A0 =A0 =A0always use PV drivers (but they've already been modifie= d).
>
> =A0 =A0 =A0 =A0b. we had done some changes to netback and netfront(as = mentioned in
> =A0 =A0 =A0 =A0the previous email), when compiling kernel for dom0 it = includes both
> =A0 =A0 =A0 =A0netfront and netback and assumed via some mechanism thi= s netfront
> =A0 =A0 =A0 =A0driver would be integrated/installed into guest domains= when they are
> =A0 =A0 =A0 =A0installed.
>
> =A0 =A0 =A0No. =A0A dom0 kernel doesn't have much use for frontend= s. =A0They're usually
> =A0 =A0 =A0present because a given kernel can run in either the dom0 o= r domU roles.
>
> =A0 =A0 =A0 =A02. Any front or back driver communication is via xenbus= only?
>
> =A0 =A0 =A0Xenbus is used to pass small amounts of control/status/conf= ig
> =A0 =A0 =A0information between front and backends. =A0Bulk data transf= er is usually
> =A0 =A0 =A0handled with shared pages containing ring buffers, and even= t channels
> =A0 =A0 =A0for event signalling.
>
> =A0 =A0 =A0 =A03. Supporting ioctl calls. Our driver has ioctl support= to read/write
> =A0 =A0 =A0 =A0hardware registers and one solution was to use pci pass= through
> =A0 =A0 =A0 =A0mechanism, however, it binds the NIC to a specific domU= and we do not
> =A0 =A0 =A0 =A0want that. We would like to have multiple users access = to hw
> =A0 =A0 =A0 =A0registers(mainly stats and other stuff) via guest domai= ns and be able
> =A0 =A0 =A0 =A0to access them simultaneously. For this, we decided to = go with the
> =A0 =A0 =A0 =A0mechanism of shared memory/event channel similar to fro= nt and back
> =A0 =A0 =A0 =A0drivers. =A0Can you please provide some inputs on this?=
>
> =A0 =A0 =A0It's hard to make any suggestions without knowing what = your hardware is
> =A0 =A0 =A0or what the use-cases are for these ioctls. =A0Are you sayi= ng that you
> =A0 =A0 =A0want to give multiple domUs direct unrestricted (read only?= ) access to
> =A0 =A0 =A0the same set of registers? =A0What kind of stats? =A0Do gue= sts need to read
> =A0 =A0 =A0them at a very high rate, or could they fetch accumulated r= esults at a
> =A0 =A0 =A0lower rate?
>
> =A0 =A0 =A0 =A0 J
>
> References
>
> =A0 =A0Visible links
> =A0 =A01. mailto:jeremy@goop.org

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenso= urce.com
> htt= p://lists.xensource.com/xen-devel


--000e0cd104f44cef980480104dd8-- --===============0446285472== 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 --===============0446285472==--