xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ritu kaur <ritu.kaur.us@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: modifying drivers
Date: Thu, 18 Feb 2010 16:03:49 -0800	[thread overview]
Message-ID: <29b32d341002181603v4664b3ebn8b8a89b88f2ab63c@mail.gmail.com> (raw)
In-Reply-To: <1266511171.10261.2027.camel@zakaz.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 2864 bytes --]

On Thu, Feb 18, 2010 at 8:39 AM, Ian Campbell <Ian.Campbell@citrix.com>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 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. 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
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3742 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2010-02-19  0:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18 16:27 modifying drivers Ritu kaur
2010-02-18 16:39 ` Ian Campbell
2010-02-19  0:03   ` Ritu kaur [this message]
2010-02-19  9:07     ` Ian Campbell
2010-02-19 17:12       ` Ritu kaur
2010-02-19 17:24         ` Ian Campbell
2010-02-19 22:30           ` Ritu kaur
2010-02-20  0:22             ` Jeremy Fitzhardinge
2010-02-20  2:15               ` Ritu kaur
2010-02-20  3:03                 ` Ritu kaur
2010-02-21 13:03                   ` Problems with Xen 4.0-rc4 forcedeth driver / Regression? Carsten Schiers
2010-02-20  7:29                 ` modifying drivers Daniel Stodden
2010-02-20 11:58                 ` Pasi Kärkkäinen
2010-02-20 23:10                   ` Ritu kaur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29b32d341002181603v4664b3ebn8b8a89b88f2ab63c@mail.gmail.com \
    --to=ritu.kaur.us@gmail.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).