Re: [Xen-devel] modifying drivers

[Ritu kaur <ritu.kaur.us@xxxxxxxxx>]

On Fri, Feb 19, 2010 at 1:07 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Fri, 2010-02-19 at 00:03 +0000, Ritu kaur wrote:
>
>
> On Thu, Feb 18, 2010 at 8:39 AM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxx> wrote:
>         On Thu, 2010-02-18 at 16:27 +0000, Ritu kaur wrote:
>         > Hi,
>         >
>         > I am modifying netback driver code such that it allows
>         access to only
>         > one domU(based on lowest domid) when multiple domUs are
>         present. When
>         > the domU with the lowest domid is suspended then the next
>         domU in the
>         > list will get access.
>
>
>         Why?
>
>         >  I believe it can be done via xe/xm commands or via Citrix
>         Xencenter
>         > by selecting or deselecting during vm installation or by
>         adding and
>         > deleting nics, however, I wanted to control this from
>         netback driver.
>
>
>         The toolstack is exactly the correct place to make and
>         implement this
>         sort of policy decision -- it has no place in the kernel
>         netback driver.
>
> Hi Ian,
>
> Consider a case when I have multiple domU's and both have NIC's
> installed. From one domU, i would like to run nightly scripts which
> involve
>
> 1. download fpga code
> 2. bringup the driver
> 3. start the test scripts in a domU which checks for packets
> transmitted/received. During this time, I would like exclusive access
> to my domU only.
>
> One way to do it is via xe/xm cli or xencenter deleting the NIC from
> the other domU or letting the user of the other domU know that tests
> are running and not access the NIC (if there is any other way to do it
> let me know), which to me is a overhead

It's not overhead, it is the *right* way to implement control operations
of this sort. Your QA scripts are ideally placed to do this.

Can you elaborate on this? If I understand this correctly, you are saying QA scripts written by us can be used to  access or restrict  i.e run these scripts from dom0 and allow or restrict access to a specific domU? I am not aware if this is possible without modifying toolstack?

>  and we want to avoid it by modifying netback drivers. By the way,
> plan is to have seperate netback/netfront for our NIC such that it
> doesn't meddle with existing drivers.

What functionality is the existing netback missing that requires you to
fork it? netback is supposed to be independent of any specific hardware.
Netback usually interacts with actual physical NICs via bridging,
routing or NAT within domain 0 (bridging being most common) to the
regular NIC driver -- there is nothing Xen or netback specific about
this operation.

You should be aware the requiring users of your hardware to install
complete new front and backend drivers as well as new toolstack support
is likely to be a large barrier to the use of your hardware.

Furthermore the Xen project is not likely to be interested in a fork of
netback to support a single piece of hardware so your chances of getting
your work accepted are low. The same is true of the upstream OS projects
(e.g. Linux) where the net{front,back} drivers actually run.

Are you sure you shouldn't be looking at PCI passthrough support or
something of that nature?

We are looking into this option as well. However from the following wiki it seems we have to compile guest OS with pcifrontend driver support.

http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module?highlight=%28pci%29
 
We are looking at different ways to accomplish the task and clearly we would like to test out all options before making a decision.

Modifying netback is one of the options(not the final one) and clearly the changes we are doing has nothing netback specific, modifying and testing it out doesn't hurt either. Appreciate if you or someone on the list can provide some inputs on debugging the issue I mentioned in my first email.

Thanks

Ian.

>  Hence would like some inputs w.r.t debugging the netback tx/rx code.
>
> Thanks
>
>
>
>         Ian.
>
>
>         >  For this,
>         >
>         > 1.  keep track of devices created via netback_probe function
>         which is
>         > called for every device.
>         > 2. Use domid field in netif_st data structure
>         > 3. Added new function netif_check_domid and placed it along
>         with
>         > netif_schedulable, I add a check if netif->domid is the
>         lowest one(via
>         > list created in step 1)
>         > 4. Function netif_schedulable is called from
>         > a. tx_queue_callback
>         > b. netif_be_start_xmit
>         > c. net_rx_action
>         > d. add_to_net_schedule_tail
>         > e. netif_be_int
>         >
>         > This works fine for the first vm that comes up. However,
>         subsequent vm
>         > bringup has issues which reboots dom0 itself.
>         >
>         > 5. I removed the function added by me in function
>         netif_be_start_xmit
>         > only, this allows multiple vm's to be up and will allow only
>         first vm
>         > to access netback. However, this has issues with the second
>         > functionality I would like to have i.e when first vm is
>         suspended,
>         > next vm in the list should get access. I added kernel
>         printfs in above
>         > functions and none of them are called after first vm is
>         suspended and
>         > subsequent vm is trying to access.
>         >
>         > Wanted to know inputs from experts on this and how to
>         proceed with
>         > debugging.
>         >
>         > Thanks
>         >
>
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel