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

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

On 15 March 2013 21:02, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 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?
Yes, and I've passed hardware through in Esxi 5.1. It's a server
chipset with IOMMU, but pre Nehalem so the features are less complete.

>> 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?
Yes. I'm given to understand the passthrough parameter should maintain
the BDF - but it doesn't, and there appears to be no advice on this on
the Internet other than 'it should work' (but doesn't for some

>> 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?

I don't know - that's why I'm asking :). I don't mind doing a bit of
debug work but I'm getting a little tired of trying kernels just in
case it might work.

>> 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?

No, you're thinking of the 3C509. The 3C900 is an old PCI 10Mb NIC. It
may be this is far too old and I need to try something newer (it was
only as a test and was to hand).

>> 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:

Can I ask which kernel you are using, please?

> builder='hvm'
> memory = 2048
> name = "Windows7"
> vcpus=3
> disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
> vnc=1
> videoram=8
> vnclisten=""
> 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.



Xen-devel mailing list



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