Re: [Xen-devel] modifying drivers

Ritu kaur
Sat, 20 Feb 2010 03:03:17 -0000

Hi Jeremy,

Sorry I missed your inputs on ioctls.

1. Stats are normal tx/rx/errors related to nic''s. Sanity tests make
sure
driver is sane by reading and comparing stats. In addition, users can
read/write specific registers which will help in debugging(one case is to
make sure correct version of fpga code is loaded or users in domU can just
make sure driver is working fine by reading stats register individually)

2. multiple users in domU need access to register read/write.

Idea is this

1. ioctl call is issued by application(sanity test or individual user
reg_read/reg_write executables)
2. ioctl is intercepted by frontend driver or some module in kernel(not sure
how to do it yet)
2. via shared memory frontend and backend drivers or kernel modules
communicate.
4. backend driver or kernel module sends ioctl call to actual driver(not
sure how to do it)
5. for reg read, data is sent from backend->frontend->actual driver
6. for reg write, data is from frontend->backend->actual driver.

Thanks


On Fri, Feb 19, 2010 at 6:15 PM, Ritu kaur <ritu.kaur.us@gmail.com> 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.
>
> 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
>>