Re: [Xen-devel] modifying drivers

Ritu kaur
Sat, 20 Feb 2010 23:10:11 -0000

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            = network_open;
        netdev->hard_start_xmit = network_start_xmit;
        netdev->stop            = network_close;
        netdev->get_stats       = network_get_stats;
        netdev->poll            = netif_poll;
        netdev->set_multicast_list = network_set_multicast_list;
        netdev->uninit          = 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 = 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ärkkäinen <pasik@iki.fi> 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
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. 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.
> >
>
> In a PV guest, xennet (frontend) driver registers the network interface 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
>
> >    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
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
> >
> > References
> >
> >    Visible links
> >    1. mailto:jeremy@goop.org
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel