All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Peter Kay <syllopsium@syllopsium.co.uk>
Cc: xen-devel@lists.xen.org
Subject: Re: Debugging passthrough on an S3210SHLC
Date: Mon, 25 Mar 2013 09:15:17 -0400	[thread overview]
Message-ID: <20130325131517.GA11546@phenom.dumpdata.com> (raw)
In-Reply-To: <CAN4OnogeCKXhm1AN_V9nQ=Ya+r0REeFBBeRTDpXOnHSaemjfKg@mail.gmail.com>

On Fri, Mar 22, 2013 at 07:24:43PM +0000, Peter Kay wrote:
> On 19 March 2013 14:54, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@oracle.com> 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@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  reply	other threads:[~2013-03-25 13:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 14:00 Debugging passthrough on an S3210SHLC Peter Kay
2013-03-15 21:02 ` Konrad Rzeszutek Wilk
2013-03-16 16:05   ` Peter Kay
2013-03-19 14:54     ` Konrad Rzeszutek Wilk
2013-03-22 19:24       ` Peter Kay
2013-03-25 13:15         ` Konrad Rzeszutek Wilk [this message]
2013-03-25 13:50           ` Sander Eikelenboom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130325131517.GA11546@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=syllopsium@syllopsium.co.uk \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.