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

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



On Fri, Mar 22, 2013 at 07:24:43PM +0000, Peter Kay wrote:
> On 19 March 2013 14:54, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> > On Sat, Mar 16, 2013 at 04:05:19PM +0000, Peter Kay wrote:
> >> 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.
> >
> > Oh. I didn't know that such mutants existed :-)
> Yes - it's the original VT-d, as supported by the Q35, Q45, X38, X48
> and S3200/S3210 chipsets (not on all motherboards). The Nehalem and
> later supporting chipsets is termed by Intel as VT-d2 as it features
> interrupt remapping, etc (except where it doesn't due to errata, as
> per recent messages to the devel list).
> 
> >> 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
> >> people).
> >
> > That depends. The xen-pciback.vpci argument that define whether you
> > want them to be virtual (so they start at 00) or match your host.
> >
> > But that option is only usefull for PV guests. I think you are using
> > an HVM one. In which that does not matter that much I would think.
> Yes, I'm using HVM. I'll have a look at vpci though, thanks!
> 
> Anyway, thank for the other recommendations - I've actually made a
> fair bit of progress.
> 
> I swapped out the 3C900 for an 82557 (Pro 100) and everything started
> working. Once I turned off video output completely and passed through
> the embedded G200e (primary video on) I was also successfully able to
> use X with it on a Wheezy HVM.

Nice!
> 
> I've yet to get the 6950 working - it's seen, identified and bound to,
> but then I get drm errors - there's no /dev/dri/card* devices. I'll
> try swapping the fglrx driver for radeon and fiddling. Failing all
> that I may try with the Fedora config that works for you. The one time
> I got the 6950 to do something the fan ran at full pelt and hung the
> whole machine, which really was a bit suboptimal.. Then again, I do
> also have the relaxed option set for xen.

I only had tried with Windows 7 guest doing the passthrough. The one time
I did try with Linux the issues I saw were that the BIOS was not
passed in - but I cannot remember if this was just as a PV (so was
using xen-pcifront, which does not expose the ROM BAR), or HVM.

For HVM, I would think I need to stuff the BIOS of the radeon card
somewhere in QEMU similary to how some people need to do it with Nvidia.
If you look around on xen-devel there are some patches floating around
from David TECHER that explain what he had to do.

Note, for debugging the Linux, I would suggest drm.debug=255
on the Linux command line. There is probably some radeon.XXX option as well
but I can't remember what it is called.

> 
> Thanks!
> 
> PK
> 
> _______________________________________________
> 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®.