From: Michael J Coss <mjcoss@alcatel-lucent.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Nvidia, Xen, and Vt-d
Date: Thu, 10 Sep 2009 05:46:13 -0400 [thread overview]
Message-ID: <4AA8CAE5.2010804@alcatel-lucent.com> (raw)
In-Reply-To: <4AA80A47.9000707@goop.org>
Jeremy Fitzhardinge wrote:
> On 09/09/09 01:56, Keir Fraser wrote:
>
>> On 09/09/2009 09:47, "Michael J Coss" <mjcoss@alcatel-lucent.com> wrote:
>>
>>
>>
>>> I've tried 3.4.1, and the lastest xen-unstable. I've tried the pv-ops
>>> git tree as I really need a 2.6.31 dom0 kernel for other reasons, but
>>> for the moment I'd just like to get to the point where I have Xen, and
>>> dom0 and Nvidia playing nicely with one another, so I can move on to
>>> working on Vt-d and graphic pass through.
>>>
>>> Any suggestions?
>>>
>>>
>> Unless you really must have 2.6.30+, I'd recommend the 2.6.27 tree and
>> patchqueue from http://xenbits.xensource.com/XCI. Otherwise you are likely
>> to have to get your hands fairly dirty with pv_ops. For example, afaik
>> starting an X server on pv_ops is still pretty ambitious on some systems.
>>
>>
>
> Starting X in dom0 seems to work OK for Intel and ATI systems, at least;
> I expect most DRM drivers would work OK if they're well-behaved because
> we're hooking AGP memory accesses, etc. However, the proprietary Nvidia
> drivers are problematic, though I gather there are some patches floating
> around for them.
>
> Unfortunately the AGP hooks are being removed (some years after Keir
> first added them, and just as they have a user according to their
> original intent) in favour of making each driver use the DMA API to do
> the appropriate phys<->bus conversions. So far, only the Intel driver
> has been converted, and only when Intel IOMMU is enabled. However, I
> didn't get any objection from the DRM folks about making it
> unconditional or adding it to new drivers as needed.
>
> J
>
I suspected as much, although I don't understand the origin of the lspci
discrepancies between booting with/without the hypervisor. It seems to
me that there is some problem with Xen's view of the PCI bus, as well as
the fact that the Nvidia driver is trying to access something outside of
the hooked APIs. The graphics cards in the system are the dual GPU,
dual slot cards, and maybe this is contributing to the problem. I'm
going to see about getting some other single slot Nvidia card and see if
the same issue happens. I may pick up some ATI cards as well.
---Michael J Coss
next prev parent reply other threads:[~2009-09-10 9:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 8:47 Nvidia, Xen, and Vt-d Michael J Coss
2009-09-09 8:56 ` Keir Fraser
2009-09-09 20:04 ` Jeremy Fitzhardinge
2009-09-10 9:46 ` Michael J Coss [this message]
2009-09-10 10:12 ` Tim Moore
2009-09-14 21:31 ` Michael J Coss
2009-09-15 7:07 ` Pasi Kärkkäinen
2009-09-09 9:17 ` Pasi Kärkkäinen
2009-09-09 11:26 ` Michael J Coss
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=4AA8CAE5.2010804@alcatel-lucent.com \
--to=mjcoss@alcatel-lucent.com \
--cc=xen-devel@lists.xensource.com \
/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.