[Xen-devel] Re: Xen 3.4 multi-function pass-through tree, isn't working...

[Tom Rotenberg <tom.rotenberg@xxxxxxxxx>]

Simon,

First of all, my workaround seems to work ok, so i think you should
consider including it anyway (if there was an exception during state
retrieval, then the state should be unknown, instead of throw an
exception). Do u think you will add this patch to the multi-function
code?

I'm reproducing this, on a Lenovo T500 machine, which is different
than your machine, since it also contains the 00:1a.2 device.
Also, i don't specify the devices to be pass-through in the boot line,
but rather, bind them to pciback after the machine boots.

This is the result of 'lspci' on my machine:
t500-testing:~# lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI
Express Graphics Port (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series
Chipset MEI Controller (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network
Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI
Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN
[Shiloh] Network Connection
04:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 11)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 21)
15:00.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)
15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host
Adapter (rev 11)
15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11)

So, do u have any idea about the problem?

Tom


On Tue, Jul 21, 2009 at 6:23 AM, Simon Horman<horms@xxxxxxxxxxxx> wrote:
> On Mon, Jul 20, 2009 at 03:11:29PM +0300, Tom Rotenberg wrote:
>> This setup worked with the plain xen 3.4 tree.
>> No custom stuff in /etc/xen/hvm.
>>
>> I took a look at the bug, and wrote a workaround for it. Take a look,
>> and tell if it's ok:
>>
>> diff -r 776ab1bec020 tools/python/xen/xend/server/pciif.py
>> --- a/tools/python/xen/xend/server/pciif.py     Sun Jul 19 11:53:11 2009 
>> -0400
>> +++ b/tools/python/xen/xend/server/pciif.py     Mon Jul 20 08:17:34 2009 
>> -0400
>> @@ -499,7 +499,13 @@
>>          num_devs = int(self.readBackend(devid, 'num_devs'))
>>          new_num_devs = 0
>>          for i in range(num_devs):
>> -            state = int(self.readBackend(devid, 'state-%i' % i))
>> +            try:
>> +                state = int(self.readBackend(devid, 'state-%i' % i))
>> +            except:
>> +                state = xenbusState['Unknown']
>> +
>>              if state == xenbusState['Closing']:
>>                  # Detach I/O resources.
>>                  pci_dev = parse_pci_name(self.readBackend(devid, 'dev-%i' % 
>> i))
>>
>> What do u think this bug is caused from?
>
> Hi Tom,
>
> your work around seems entirely reasonable, but I am still puzzled at
> how your system gets into this state. I'm having no luck reproducing it
> here.
>
> I have the following passed to the dom0 kernel at boot:
>
> root=/dev/mapper/sam-root_x86_64 console=ttyS0 loglevel=8 ro 
> pciback.hide=(01:00.0)(01:00.1)(00:1b.0)(00:1a.0)(00:1a.1)(00:1a.7)(00:1d.0)(00:1d.1)(00:1d.2)(00:1d.7)(07:b.0)(07:04.0)
>  reassign_resources reassigndev=00:1d.7
>
> And I'm starting a domU with all USB devices passed-through using:
>
> xm create -c /home/horms/hvm xen_platform_pci=0 pci='00:1a.0' pci='00:1a.1' 
> pci='00:1a.7' pci='00:1d.0' pci='00:1d.1' pci='00:1d.2' pci='00:1d.7'
>
> To test multi-function pass-through I also tried:
>
> xm create -c /home/horms/hvm xen_platform_pci=0 pci='00:1a.*' pci='00:1d.*'
>
> /home/horms/hvm is as follows:
>
> import os, re
> arch = os.uname()[4]
> if re.search('64', arch):
>    arch_libdir = 'lib64'
> else:
>    arch_libdir = 'lib'
> kernel = "/usr/lib/xen/boot/hvmloader"
> builder='hvm'
> memory = 128
> name = "debian"
> disk = [ 'file:/home/horms/projects/xen/media/debian-unstable.disk,hda,w' ]
> boot='c'
> device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
> sdl=0
> opengl=0
> vnc=1
> vnclisten="0.0.0.0"
> vncunused=1
> nographic=0
> stdvga=0
> serial='pty'
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel