Re: [Xen-users] pci device not owned by pciback.

[listmail <listmail@xxxxxxxxxxxx>]

search keyword co-assigned here -> 
http://wiki.xensource.com/xenwiki/XenPCIpassthrough
James Pifer wrote:
> On Tue, 2010-04-27 at 17:04 +0200, Mark Hurenkamp wrote:
>   
> > Hi James,
> >
> >
> >     
> > > > Error: pci: improper device assignment specified: pci: 0000:0e:04.0 must
> > > > be co-assigned to the same guest with 0000:0e:04.0, but it is not owned
> > > > by pciback.
> > > >         
> > What Xen version are you using? Are you using a pvops based kernel? Or a
> > 'classic' xen kernel based on 2.6.18+patches?
> > Are you sure it mentions the exact same id twice? It is more likely to
> > report two almost identical ids, with a small difference in the last
> > digit... (e.g. 0000:0e:04.1 must be co-assigned with 0000:0e:04.0)
> >
> >     
> > > > How do I make this card owned by pciback on reboot. Do I need to use the
> > > > hide parameter on the kernel line on boot?
> > > >         
> > > It says to add something like this to the module line:
> > > pciback.hide=(01:00.0)(00:02.0)
> > >       
> > For older kernel versions, you should use the command as stated above. For
> > newer versions, the module is renamed to xen-pciback, and you'd state:
> > xen-pciback.hide=(01:00.0)(00:02.0)
> >
> >     
> > > This page talks about VT and my domU is a PV. Does this same pciback
> > > apply?
> > >       
> > Hiding is the same for VTd and for PV. However, the 'co-assigned' error
> > message is typical for VTd, it doesn't allow devices on the same PCI bus
> > to be divided over more than one vm.
> > If you are passing through a single device to a PV machine, and xen gives
> > you the above mentioned 'co-assigned' error, it is probably due to a bug
> > in xen (which appeared a while ago, but has since been fixed).
> >     
> I tried adding this to my modules line:
> module /boot/vmlinuz-2.6.27.19-5-xen 
> root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
> resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
> splash=silent showopts vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)
>
> When the system came up it looks like the host server still took control
> of the scsi card:
> 0e:04.0 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter 
> (rev 08)
>         Subsystem: Atto Technology ExpressPCI UL5D Low Profile
>         Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 30
>         I/O ports at 5000 [size=256]
>         Memory at fafc0000 (64-bit, non-prefetchable) [size=256K]
>         Memory at faf80000 (64-bit, non-prefetchable) [size=256K]
>         [virtual] Expansion ROM at e8100000 [disabled] [size=1M]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 
> Enable-
>         Capabilities: [68] PCI-X non-bridge device
>         Kernel driver in use: mptspi
>         Kernel modules: mptspi
>
> 0e:04.1 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter 
> (rev 08)
>         Subsystem: Atto Technology ExpressPCI UL5D Low Profile
>         Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 37
>         I/O ports at 5400 [size=256]
>         Memory at faf40000 (64-bit, non-prefetchable) [size=256K]
>         Memory at faf00000 (64-bit, non-prefetchable) [size=256K]
>         [virtual] Expansion ROM at e8200000 [disabled] [size=1M]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 
> Enable-
>         Capabilities: [68] PCI-X non-bridge device
>         Kernel driver in use: mptspi
>         Kernel modules: mptspi
>
> I tried unloading mptspi and it unloads, but I still can't start the
> virtual machine assigned those cards. Same error as before:
> Error: pci: improper device assignment specified: pci: 0000:0e:04.0 must be 
> co-assigned to the same guest with 0000:0e:04.0, but it is not owned by pciback.
>
> It's weird that it worked yesterday, but the difference was we plugged
> in the DLT drive AFTER the hosts system was already running. 
>
> Looked at dmesg:
> # dmesg | grep pciback
> Command line: 
> root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
> resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
> splash=silent vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)
> Kernel command line: 
> root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
> resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
> splash=silent vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)
> Unknown boot option `pciback.hide=(0e:04.0)(0e:04.1)': ignoring
>
> So then I tried xen-pciback:
> # dmesg | grep pciback
> Command line: 
> root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
> resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
> splash=silent vga=0x317 xen-pciback.hide=(0e:04.0)(0e:04.1)
> Kernel command line: 
> root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
> resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
> splash=silent vga=0x317 xen-pciback.hide=(0e:04.0)(0e:04.1)
> Unknown boot option `xen-pciback.hide=(0e:04.0)(0e:04.1)': ignoring
>
> Does this mean it is not compiled in the kernel? That would really suck.
>
> What would my next step be?
>
> Thanks,
> James
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>   
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users