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
____________________________________________________________________
Carsten Schiers, Henseweg 23h, 22359 Hamburg, Tel. (040) 6044 9717,
carsten@xxxxxxxxxx
----- 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
|
Home