[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
        #if defined(CONFIG_XEN) && !defined(CONFIG_PARAVIRT)
        #include <asm/maddr.h>
        #include <xen/interface/memory.h>
which suggests it doesn't currently work but I would guess that the
issue could be fixed in the glue layer and the usages of
NV_XEN_SUPPORT_OLD_STYLE_KERNEL will point towards the areas which need
consideration, there aren't too many of them...


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.