This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: vt-d p7p55d evo: Success

Pasi Kärkkäinen wrote:
On Sun, Apr 11, 2010 at 02:50:08PM -0400, listmail wrote:
- Xen version

- Dom0 kernel version, and if it's pvops or xenlinux based / Guest OS and driver version same kernel for both, via git clone of xen/stable-2.6.32 @ commit 062aaac18de6d875fcc646359179449218f486c5
packaged for install via debian's make-kpkg
used the .config attached here: http://lists.xensource.com/archives/html/xen-users/2010-03/msg00878.html

-- "lspci" output for the graphics card to get the PCI IDs and model information
dom0 lspci -vv

- Did you passthru all the PCI IDs or just one?
I'm only aware of one ID -> xen-pciback.hide=(01:00.0)

Btw did you try without hiding from dom0?
I've added your info to the wiki page now.


-- Pasi

Just a small follow up

late binding
#01:00.0 0300: 10de:0600 (rev a2)
echo "10de 0600" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind

#00:1a.0 0c03: 8086:3b3c (rev 05)
echo "8086 3b3c" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1a.0" > /sys/bus/pci/devices/0000:00:1a.0/driver/unbind
echo "0000:00:1a.0" > /sys/bus/pci/drivers/pci-stub/bind

#00:1d.0 0c03: 8086:3b34 (rev 05)
echo "8086 3b34" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.0" > /sys/bus/pci/devices/0000:00:1d.0/driver/unbind
echo "0000:00:1d.0" > /sys/bus/pci/drivers/pci-stub/bind

Results were the same.  I noticed a message:
pciback pci-1-0: 22 Couldn't locate PCI device (0000:01:00.0)! perhaps already in-use?

Maybe this is because I'm doing all of this from script and immediately starting the hvm. Could use a delay?

I also patched in load BIOS from file and results were the same

The only thing *new* that I've noticed is that when power saving/screen blank occurred on console, mouse/keyboard (usb controllers passed through per above) movement from domU would not wake it up. I thought perhaps it was actually coming in from setterm on dom0. If this is the case I assume setterm -blank 0 -powersave off -powerdown 0 may handle that.

Xen-devel mailing list