|
|
|
|
|
|
|
|
|
|
xen-devel
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>
#define NV_XEN_SUPPORT_OLD_STYLE_KERNEL
#endif
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...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|