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
next prev parent 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).