This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-users] pv_ops kernel and nvidia binary driver

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] pv_ops kernel and nvidia binary driver
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 15 Jul 2009 09:57:35 -0700
Cc: Boris Derzhavets <bderzhavets@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Michael Ralston <michael@xxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Jul 2009 09:58:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1247645673.13493.65.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <701488.94378.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A5CE1E6.2010503@xxxxxxxx> <1247645673.13493.65.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2
On 07/15/09 01:14, Ian Campbell wrote:
> On Tue, 2009-07-14 at 20:52 +0100, Jeremy Fitzhardinge wrote:
>> The problem comes down to whether the nvidia driver assumes the kernel's
>> (pseudo-)physical addresses are really machine physical or not.  If it
>> doesn't do the appropriate conversions between physical and machine
>> addresses using the standard Linux DMA API (or similar), then it will
>> end up misprogramming the hardware and reading/writing random memory. 
>> There's not a lot we can do about that if that happens within the binary
>> part of the nvidia driver.  If the binary code calls out to the
>> source-available parts of the driver to do those conversions, then it
>> would be possible to fix there.
> I've been running the Nvidia driver on an old style Xen kernel for quite
> a while now so I guess it will be possible to make it work for pvops
> too. The glue layer contains:
>         /*
>          * Traditionally, CONFIG_XEN indicated that the target kernel was
>          * built exclusively for use under a Xen hypervisor, requiring
>          * modifications to or disabling of a variety of NVIDIA graphics
>          * driver code paths. As of the introduction of CONFIG_PARAVIRT
>          * and support for Xen hypervisors within the CONFIG_PARAVIRT_GUEST
>          * architecture, CONFIG_XEN merely indicates that the target
>          * kernel can run under a Xen hypervisor, but not that it will.
>          *
>          * If CONFIG_XEN and CONFIG_PARAVIRT are defined, the old Xen
>          * specific code paths are disabled. If the target kernel executes
>          * stand-alone, the NVIDIA graphics driver will work fine. If the
>          * kernels executes under a Xen (or other) hypervisor, however, the
>          * NVIDIA graphics driver has no way of knowing and is unlikely
>          * to work correctly.

The whole point of pvops and the other changes is that they don't need
to care whether its running under Xen.  They must be going around the
standard APIs, and doing something special for the Xen case.   Of
course, they can always use the xen_domain() predicates to make that
code runtime conditional if they want to do it that way...


Xen-devel mailing list