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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Monday, March 25, 2013, 2:15:17 PM, you wrote:

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

When using secondary passthrough to a hvm (on xen-unstable and qemu upstream 
and recent kernel) it can work out out of the box (on a HD-65xx) (tested with 
debian wheezy and ubuntu).
Don't know when you try to use it as primary though.

Suing the fglrx is quite a pain in the ass on kernels > 3.5 due to the UAPI 
reshuffling.

--
Sander

> 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