pciback

pciback

[ron minnich]

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

Re: pciback

[Keir Fraser]

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

Re: pciback

[ron minnich]

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

Re: pciback

[Ian Campbell]

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

Re: pciback

[ron minnich]

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

Re: pciback

[ron minnich]

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 ] ; then

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.
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

Re: pciback

[Ian Campbell]

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.

Re: pciback

[ron minnich]

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

Re: pciback

[Ian Campbell]

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.

Re: pciback

[ron minnich]

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

pciback

[Teo En Ming (Zhang Enming)]

Hi,

Does the kernel configuration parameter CONFIG_XEN_PCIDEV_BACKEND refer 
to pciback?

I have another 2 questions.

(1) If CONFIG_XEN_PCIDEV_BACKEND is compiled in, can I pass the pciback 
argument to the kernel command line in GRUB configuration?

(2) If CONFIG_XEN_PCIDEV_BACKEND is compiled as a module, what should I 
do if I want to passthrough VGA and PCI devices to the HVM guest?

Thank you very much.

Yours sincerely,

Teo En Ming (Zhang Enming)

Re: pciback

[Fajar A. Nugraha]

On Mon, Mar 19, 2012 at 9:25 AM, Teo En Ming (Zhang Enming)
<singapore.mr.teo.en.ming@gmail.com> wrote:
> Hi,
>
> Does the kernel configuration parameter CONFIG_XEN_PCIDEV_BACKEND refer to
> pciback?
>
> I have another 2 questions.
>
> (1) If CONFIG_XEN_PCIDEV_BACKEND is compiled in, can I pass the pciback
> argument to the kernel command line in GRUB configuration?
>
> (2) If CONFIG_XEN_PCIDEV_BACKEND is compiled as a module, what should I do
> if I want to passthrough VGA and PCI devices to the HVM guest?


I'd start by using Google to search the archives first, possibly start
from: http://lists.xen.org/archives/html/xen-devel/2012-01/msg00378.html

-- 
Fajar