[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Debugging passthrough on an S3210SHLC



On Fri, Mar 01, 2013 at 02:00:08PM +0000, Peter Kay wrote:
> I'm having difficulty getting any passthrough working on an S3210SHLC (X38 
> derived S3210 socket 775 server chipset, thus pre SLAT) - this is on the list 
> of supported hardware. Is there any guide as to what can be done - I've tried 
> iommu=verbose, so is the next step sending debug printfs to the xen console? 
> I realise this is a development list so I'd like advice on which bits of 
> source to poke so I can find the root issue.
> 

This hardware has actual IOMMU?

> The hardware does work - I've passed the embedded G200e through using ESXi 
> 5.1 although other devices (a Radeon 6950) don't work.
> 
> Issues are - both with XCP1.6 and xen 4.2 (with some small AMD VGA 
> passthrough patches)/xen 4.3 unstable on Debian Wheezy :
> 
> Pciback is a module. It recognises the passthrough keyword but PCI IDs are 
> still modified in VMs.


Not sure what you mean by that. Modified in VMs? You mean that the BDF value is 
different?

> 
> Pt_iomul errors in qemu log even though the status is 'successful'
> 
> Xl create errors out with a gnttab error both in 4.2/4.3. Xm works.

Uh, that is not good. Why would 'xl' die on that? Is that fixed with a different
version of the Linux kernel?

> 
> When passing through an old 3C900 PCI NIC as a test, this causes noise in the 
> audigy 4 PCI soundcard in the next slot unless that is also passed through. I 
> suspect this is due to the bus layout of the S3210SHLC. Is it always 
> necessary to pass all PCI devices on the same root through? Also should it be 
> necessary/possible to pass a PCI root?
> 

Isn't that an ISA card? Do you mean 3c590 perhaps?

> The VMs think the device was successfully passed through (a wheezy hvm binds 
> the appropriate modules and a Windows 7 hvm has seen the radeon) but they 
> don't actually work.
> 
> There are so many combinations of hardware and kernel finding out what is 
> wrong is tricky. I'd appreciate some advice diagnosing it.

So I've been quite successfull with both AMD and Intel to pass in a PCIe type 
NIC. And also
an Radeon card in Windows 7:

04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
06:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV770 
[Radeon HD 4870]
06:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV770 HDMI Audio 
[Radeon HD 4850/4870]

Without any modifications to Xen. Just used Fedora 18 and use xen-pciback.hide 
to hide
the 04:00.0 and 06:00.* and passed them in to the guest:

builder='hvm'
memory = 2048
name = "Windows7"
vcpus=3
disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
usb=1
usb_add="host:045e:0040"
usbdevice='tablet'
xen_platform_pci=1
# Remember QEMU_AUDIO_DRV=pa
soundhw='es1370'
pci=['04:00.0','06:00.1','06:00.0']

> 
> Hardware is S3210SHLC with latest (52) BIOS, embedded Matrox G200e, two 
> E1000s of some type, a GeForce G210 (for console), Reference AMD 6950 (on the 
> PCH 4x slot as MCH slot bandwidths are restricted for graphics cards), audigy 
> 4 PCI and 3C900.
> 
> Cheers!

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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.