xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: philip tricca <flihp@twobit.us>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: no udev events in netback domU driver domain 2.6.32.14
Date: Thu, 08 Jul 2010 17:34:20 -0400	[thread overview]
Message-ID: <4C36445C.3040907@twobit.us> (raw)
In-Reply-To: <20100707134505.GC4823@phenom.dumpdata.com>

Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2010 at 10:04:03PM -0400, philip tricca wrote:
>> I've spent a bit trying to configure and unprivileged network driver
>> domain using the current 2.6.32.14 pvops kernel (haven't up'd to .15
>> due to incompatibility with 4.0.0 release).  I've been partially
>> successful but am failing in what I'd think would be the last step:
>> getting udev rules to fire when attaching network devices using
>> xen-netback & xen-netfront drivers.  From my reading of the pvops
>> wiki page there's a possibility that the wiring between the drivers
>> and the udev events may not have been forward ported completely.  In
>> fact, using 'udevadm monitor' I don't see any events at all when the
>> vif is created in the driver domain and when eth0 is created in the
>> client (both are created when xm network-attach is run).
> 
> You won't see the 'eth0' being created from Dom0 side. But you should
> see the rest:

Correct.  I don't see any udev events from dom0: the nic is passed to a 
domU (call it a driver domain) through pciback so all of the vif events 
happen there.  Another domU is getting its eth0 through the netback 
offered up by the driver domain

>> Is anyone familiar enough with these portions of the driver to
>> comment on this?  If this "should" be working I can post the details
>> of my setup and debug information if necessary but I don't want to
>> flood the list with a huge email if it isn't necessary.
> 
> This is what I get:
> 
> [root@phenom ~]#  udevadm monitor --kernel --env --property
> monitor will print the received events for:
> KERNEL - the kernel uevent

<snip\>

I am now getting the right udev events (the same ones Konrad shows) in 
both my driver domain and in the client.  The problem I am still having 
is related to the xenstore.

The network scripts run by udev access data in the xen store and use it 
to return status information to dom0:
/local/domain/X/backend/vif/Y/Z/hotplug-status
The xenstore is completely inaccessible from my driver domain however. 
I've installed the xenstored daemon in the driver domain which requires 
running it with the --no-domain-init option to keep it from trying to 
execute privileged operations (it's not dom0).

Even with the xenstored daemon running though I (and the networking 
scripts) still can't access then xenstore.

I'm making progress but I could use a hint if someone's got one.

Cheers,
- Philip

  reply	other threads:[~2010-07-08 21:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07  2:04 no udev events in netback domU driver domain 2.6.32.14 philip tricca
2010-07-07 13:45 ` Konrad Rzeszutek Wilk
2010-07-08 21:34   ` philip tricca [this message]
2010-07-12 15:13     ` Konrad Rzeszutek Wilk
2010-07-14 21:16       ` philip tricca
  -- strict thread matches above, loose matches on Subject: below --
2010-07-09 19:27 no udev events in netback domU driver domain, 2.6.32.14 Steven Harp

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=4C36445C.3040907@twobit.us \
    --to=flihp@twobit.us \
    --cc=konrad.wilk@oracle.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).