Re: [Xen-users] PCI passthrough to Windows XP

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-11-08 at 18:36 +0000, Daniel E. Shub wrote:
> I am trying to run Windows XP in a Xen DomU virtual machine with a PCIe 
> device, for which there are no Linux drivers, being passed through from a 
> Debian Squeeze Dom0. My hardware supports virtualization and it is active in 
> the bios. If I run 
> grep -E "(vmx|svm)" --color=always /proc/cpuinfo
>  
> when I boot from the standard kernel I can see my processor supports vmx, 
> although when I boot the Xen kernel, vmx doesn't show up. 

I think this is normal -- since Xen uses the vmx/svm capability it is
not available to dom0 and therefore is masked.

> I have followed the setup in http://wiki.xen.org/wiki/Xen_Beginners_Guide. 
> The 
> guide basically creates a minimal Debain Squeeze install as Dom0, a PV Debian 
> Squeeze DomU and a HVM Windows DomU running on an LVM volume. I have followed 
> the guide essentially to the letter with the only differences being my 
> network 
> bridge is different and I didn't install a Debian PV DomU. 
> I currently have a DomU on an LVM volume that is running a fully updated 
> version of Windows XP with the GPLPV drivers. I am now trying to pass the PCI 
> device, but am running into problems. If I compare the output of lspci with 
> and without the PCIe card that I am trying to pass I see the following two 
> new 
> entries: 
> 05:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge 
> (rev 21) 
> 06:04.0 Bridge: Device 4550:9054 (rev 01) 
> I also see that another entry has changed its address from 

Changed compared to what?

> 06:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II 
> Controller (rev b2) 
> to 
> 07:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II 
> Controller (rev b2) 
> I modified /etc/default/grub to include either 
> GRUB_CMDLINE_XEN="xen-pciback.hide=(05:00.0)(06:04.0)"
>  
> or 
> GRUB_CMDLINE_XEN="pciback.hide=(05:00.0)(06:04.0)"

Which dom0 kernel version are you running? Are you certain the the
pciback module is enabled and builtin (not a module)? This syntax
(exactly which depends on the kernel version) only works for when
pciback is statically compiled. If it is modular then you need the
bind/unbind dance which you described below.

> and run update-grub and update-grub2 after making the change and then fully 
> powered down and rebooted. This doesn't appear to do anything and nothing 
> shows up with 
> xm pci-list-assignable-devices
>  
> Looking at the Xen wiki guide http://wiki.xen.org/wiki/Xen_PCI_Passthrough I 
> have tried things like 

For the purposes of trouble shooting it would be useful to include the
actual literal commands you ran rather than something "like" them.

> echo 0000:05:00.0 > /sys/bus/pci/devices/0000:05:00.0/driver/unbind
> echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/new_slot
> echo 0000:05:00.0 > /sys/bus/pci/drivers/pciback/bind
>  
> and some other stuff related to pci-stub. Sometimes my random fiddling 
> results 
> in 
> xm pci-list-assignable-devices
>  
> listing 05:00.0 and 06:04.0. If I modify my .cfg file to include 
> pci = ['05:00.0', '06:04.0']
>  
> I get an error about pci-stub not owning the 05:00.0 device. If I only try 
> and 
> pass 06:04.0 the DomU won't boot. 

Did you repeat the above bind/unbind commands for 06:04.0?

> Any ideas how to get pci passthrough working?

You don't say which version of Xen you are running but if it is 4.2 then
you may have more luck using the xl toolstack, and in particular the 
"xl pci-assignable-add" commands.

It maybe  that the presence of the bridge device is confusing things.
What is your pci topology like (lspci -t I think). TBH I'm not sure how
pci passthrough interacts with PCI bridges but my intuition is that in
general you do not want to pass thr bridge through, unless perhaps you
are passing *every* device which is behind it to the same guest.



> 
> 
> Dan
> 
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users