For a given device tree in /sys, at what point should the driver symlink say ''pciback''? I can see from the kernel the message that pciback is trying to ''seize'' the device, once I do the echo blah blah blah > /blah/blah/blah/bind. But the driver symlink never changes. Also the pcihide stuff doesn''t seem to work either. But if I cat the ''slots'' file, I do see the bus:dev.0 numbers that I am trying to tell pciback to seize. What''s the next thing I should see? Should the devices I have seized appear in the xenstore? I kind of thought, from reading the pci code front and back, that they should. thanks ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 14/12/06 3:19 am, "ron minnich" <rminnich@gmail.com> wrote:> For a given device tree in /sys, at what point should the driver > symlink say ''pciback''? > > I can see from the kernel the message that pciback is trying to > ''seize'' the device, once I do the echo blah blah blah > > /blah/blah/blah/bind. But the driver symlink never changes. > > Also the pcihide stuff doesn''t seem to work either. But if I cat the > ''slots'' file, I do see the bus:dev.0 numbers that I am trying to tell > pciback to seize. What''s the next thing I should see? Should the > devices I have seized appear in the xenstore? I kind of thought, from > reading the pci code front and back, that they should.How are you driving pciback? Xend-based toolstack in Linux dom0? Have you got as far as trying to access the PCI device from your plan9 domU yet? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/14/06, Keir Fraser <keir@xensource.com> wrote:> How are you driving pciback? Xend-based toolstack in Linux dom0? Have you > got as far as trying to access the PCI device from your plan9 domU yet?no, as I still don''t quite understand the rules here. What does ''driving pciback'' mean in this case? My guess on this sequence, from reading the drivers, was something like this: 1. pciback ''seizes'' device 2. You can this this because the ''driver'' symlink now reads ''pciback'' (has not happened) 2a. or because the ''slots'' contains the bus:dev.fn of the device (HAS happened) 3. the device becomes visible in xenstore (has not happened) 4. Ok, now what? I assume I can enumerate the device via pcifront. But my reading of the pcifront code is as follows: pcifront walks the xenstore, finds the device via bus:dev.fn, and does config space ops on it. But, is this really correct? I never see the device in the xenstore. Another thing I tried was having Plan 9 do an HYPERVISOR iopl, but this does not appear to have worked either. I''m happy to post that code is someone can tell me what I might be missing. Thanks again! ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2006-12-13 at 20:19 -0700, ron minnich wrote:> For a given device tree in /sys, at what point should the driver > symlink say ''pciback''? > > I can see from the kernel the message that pciback is trying to > ''seize'' the device, once I do the echo blah blah blah > > /blah/blah/blah/bind. But the driver symlink never changes.Did you unbind it from the current driver first? I use the script below as "./pciback 0000:05:04.0" Ian. #!/bin/sh if [ $# -eq 0 ] ; then echo "Require a PCI device as parameter" exit 1 fi for pcidev in $@ ; do if [ -h /sys/bus/pci/devices/"$pcidev"/driver ] ; then echo "Unbinding $pcidev from" $(basename $(readlink /sys/bus/pci/devices/"$pcidev"/driver)) echo -n "$pcidev" > /sys/bus/pci/devices/"$pcidev"/driver/unbind fi echo "Binding $pcidev to pciback" echo -n "$pcidev" > /sys/bus/pci/drivers/pciback/new_slot echo -n "$pcidev" > /sys/bus/pci/drivers/pciback/bind done _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/14/06, Ian Campbell <Ian.Campbell@xensource.com> wrote:> Did you unbind it from the current driver first? I use the script below > as "./pciback 0000:05:04.0" >Thanks for the script. Running it for 2:1.0 produces: [root@q xen3]# ./pciback 2:1.0 Binding 2:1.0 to pciback but: [root@q xen3]# ls -l /sys/bus/pci/devices/0000\:02\:01.0/driver lrwxrwxrwx 1 root root 0 Dec 14 10:13 /sys/bus/pci/devices/0000:02:01.0/driver -> ../../../../bus/pci/drivers/e1000 [root@q xen3]# kernel sees this: pciback: wants to seize 0000:02:01.0 What should I see? It''s not in the xenstore. If this succeeds, should it be? thanks ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/14/06, Ian Campbell <Ian.Campbell@xensource.com> wrote:> Ian. > > > #!/bin/sh > > if [ $# -eq 0 ] ; then > echo "Require a PCI device as parameter" > exit 1 > fi > > for pcidev in $@ ; do > if [ -h /sys/bus/pci/devices/"$pcidev"/driver ] ; thenIan, I think there is some difference at work here. On my system, you have to unbind in a path such as /sys/bus/pci/devices/e1000/unbind. There''s no unbind entry in the bus:dev.fn path. I also tried this,in modules.conf, but it did not work at all: # hide (0000:02:01.0) options pciback hide=(0000:02:01.0) install e1000 /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install e1000 Anyway, I finally got something to sort of go. ifdown eth0 rmmod e1000 sh pciback.sh 0000:02:01.0 I''m going to reboot and make sure this sequence works. At least now, the driver symlink for 0000:02:01.0 is pciback. But still nothing in xenstore for that device; should there be? ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-12-14 at 13:26 -0700, ron minnich wrote:> On 12/14/06, Ian Campbell <Ian.Campbell@xensource.com> wrote: > > > Did you unbind it from the current driver first? I use the script below > > as "./pciback 0000:05:04.0" > > > Thanks for the script. > > Running it for 2:1.0 produces: > [root@q xen3]# ./pciback 2:1.0>From the other output you showed I think you need to use 0000:02:01.0.It needs to precisely match the directory in /sys/bus/pci/devices/ which differs from that in the lspci output due to the extra field on the front. You will also need a matching "pci = [''0000:02:01.0'']" in your domU config.>From the other mail > Ian, I think there is some difference at work here. On my system, you > have to unbind in a path such as /sys/bus/pci/devices/e1000/unbind./sys/bus/pci/devices/0000:02:01.0/driver will be a link to ../../../../bus/pci/drivers/e1000 so it should just work based on the PCI device number thing without needing to know which driver currently owns the device. I think the pciback hide option isn''t working for you because by the time you load the pciback module the real hardware driver will have claimed the device. To make that work you probably need to build pciback statically and use the kernel command line. I''m not sure about this though since I never used this particular functionality. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian, I assumed that if I bound a device to pciback (it can bind now, see earlier mail) then I would see it in xenstore. Is this not the case? If I set up a *pci in domU, but don''t have pcifront working in domU yet, can I still see it in xenstore on domU? thanks ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2006-12-14 at 15:55 -0700, ron minnich wrote:> Ian, I assumed that if I bound a device to pciback (it can bind now, > see earlier mail) then I would see it in xenstore. Is this not the > case?I don''t think you will see anything till you configure and start a domU which uses that device.> If I set up a *pci in domU, but don''t have pcifront working in domU > yet, can I still see it in xenstore on domU?This is the point at which I would expect stuff show up in xenstore. For example when I started a domU with PCI device 0000:00:1d.00 but no pcifront driver I see these store entries: # xenstore-ls /local/domain/0/backend/pci 13 = "" 0 = "" domain = "debian-2" frontend = "/local/domain/13/device/pci/0" uuid = "e115728d-a997-4433-e586-6d3e9103c8b4" dev-0 = "0000:00:1d.00" state = "3" online = "1" frontend-id = "13" num_devs = "1" root-0 = "0000:00" root_num = "1" # xenstore-ls /local/domain/13/device/pci 0 = "" state = "1" backend-id = "0" backend = "/local/domain/0/backend/pci/13/0" When I start the same domain with a pcifront driver I get: # xenstore-ls /local/domain/0/backend/pci 14 = "" 0 = "" domain = "debian-2" frontend = "/local/domain/14/device/pci/0" uuid = "b328cab0-a704-d59f-8133-c5f053f4b639" dev-0 = "0000:00:1d.00" state = "4" online = "1" frontend-id = "14" num_devs = "1" root-0 = "0000:00" root_num = "1" # xenstore-ls /local/domain/14/device/pci 0 = "" state = "4" backend-id = "0" backend = "/local/domain/0/backend/pci/14/0" pci-op-ref = "8" event-channel = "27" magic = "7" Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
OK, Ian, thanks for the help, I am now seeing it. ifdown eth0 rmmod e1000 Run your script start domU it''s there. thanks ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel