[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |