Re: [Xen-devel] modifying drivers

Ritu kaur
Sat, 20 Feb 2010 02:15:56 -0000

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.

Jeremy/Ian, have any inputs on ioctl support?

Thanks


On Fri, Feb 19, 2010 at 4:22 PM, Jeremy Fitzhardinge
<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