AW: [Xen-users] Workaround for pcifront issues

[Carsten Schiers <carsten@xxxxxxxxxx>]

Ah, just found the patch from Dexuan. Atteched here for completeness. BR,C.

----- Originalnachricht -----
Von: Carsten Schiers <carsten@xxxxxxxxxx>
Gesendet: Mit, 4.2.2009 13:02
An: "Fischer, Anna" <anna.fischer@xxxxxx> ; xen-users@xxxxxxxxxxxxxxxxxxx
Betreff: AW: [Xen-users] Workaround for pcifront issues

Thanks Anna, this was also quite interesting for me. 

Did you mean that I just have to eliminate the else branch or raise arround 
"All devices 
behind the uppermost PCI/PCI-X bridge must be co-assigned to the same guest." 
or do I have
to eliminate more in order to prevent an FLR (whatever that is).

For my board it's definitely necessary to move PCI devices in different guests, 
as all PCI 
slots are assigned to one bridge. It works on 3.2-1. As I don't know what FLR 
is, I cannot
estimate, whether others are happy about these changes, I am definitely not. It 
prevents me
to use 3.3 upwards with its cpufreq handling.

Best Regards,
Carsten.

-[0000:00]-+-00.0  nVidia Corporation MCP65 Memory Controller
           +-01.0  nVidia Corporation MCP65 LPC Bridge
           +-01.1  nVidia Corporation MCP65 SMBus
           +-01.2  nVidia Corporation MCP65 Memory Controller
           +-02.0  nVidia Corporation MCP65 USB Controller
           +-02.1  nVidia Corporation MCP65 USB Controller
           +-06.0  nVidia Corporation MCP65 Ethernet
           +-08.0-[0000:01]--+-06.0  Matrox Graphics, Inc. MGA 2064W 
[Millennium]
           |                 +-07.0  Techsan Electronics Co Ltd B2C2 FlexCopII 
DVB chip / Technisat SkyStar2 DVB card
           |                 +-08.0  Techsan Electronics Co Ltd B2C2 FlexCopII 
DVB chip / Technisat SkyStar2 DVB card
           |                 \-09.0  Philips Semiconductors SAA7146
           +-09.0  nVidia Corporation MCP65 IDE
           +-0a.0  nVidia Corporation MCP65 AHCI Controller
           +-0c.0-[0000:02]----00.0  Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller
           +-0e.0-[0000:03]----00.0  Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller
           +-18.0  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
           +-18.1  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
           +-18.2  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
           \-18.3  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control

----- Originalnachricht -----
Von: "Fischer, Anna" <anna.fischer@xxxxxx>
Gesendet: Mit, 4.2.2009 08:42
An: Glen Eustace <geustace@xxxxxxxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Betreff: RE: [Xen-users] Workaround for pcifront issues

> Subject: [Xen-users] Workaround for pcifront issues
> 
> I have just started to try to achieve pci passthru for a BomU so that I
> can use the host secondary ethernet interfaces directly.
> 
> I am running 3.3.1 on Centos5.2 with std packages.
> 
> I have detached the card from the host using pciback but have hit an
> issue with trying to get the DomU to pick it up, it wants both 01:01.0
> and 01:01.1 even though they are totally different cards.
> 
> It seems that this issue has arisen somewhere between 3.1 and 3.3, to
> do
> with VT-d patches.  I am not using VT-d, is there a work around that
> doesn't involve applying kernel or xen patches on either Do0mU or DomU.

Yes, I have seen this as well, and I think it has to do with how the system 
supports Function Level Reset (FLR), see 
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00626.html. Your 
cards probably are behind the same PCI bridge. If you don't care about the FLR 
functionality, then you could remove the checks for this in 
tools/python/xen/xend/server/pciif.py - you just need to recompile the Xen 
tools in Dom0, but no kernel changes. This is a hack though rather than a good 
solution :( I am not sure if there are any other drawbacks for doing this.

_______________________________________________
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

Attachment: disable_FLR.patch
Description: Binary data

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