Re: Re: vt-d p7p55d evo: Success

[listmail <listmail@triad.rr.com>]

Pasi Kärkkäinen wrote:
> On Sun, Apr 11, 2010 at 02:50:08PM -0400, listmail wrote:
>   
>> - Xen version
>> 4.0-rc8
>>
>> - 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
>> <snip>
>>
>> - 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.
>
> Thanks!
>
> -- Pasi
>
>   
Just a small follow up

late binding
# VGA
#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

# USB
#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

# USB
#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.