[Xen-users] Re: NVIDIA, 2.6.30.1 patches, PV_OPS and Xen 3.4.1

[Boris Derzhavets <bderzhavets@xxxxxxxxx>]

>The files you have listed there are for the nvidia framebuffer console
>driver, not the proprietary X windows nvidia binary drivers. Do you
>have any nvidia-glx packages installed?

I checked Synaptic Manager. nvidia-glx package doesn't seem to be installed
Only nvidia-common and a several nvidia-XX-modaliases packages seem to
be installed.

>Also does your xorg logs show
>the nvidia proprietary driver being loading including glx?

I guess yes.  Xorg.0.log it's attached.

***********************************************************************
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
        compiled for 1.6.0, module version = 1.0.0
        ABI class: X.Org Server Extension, version 2.0
(==) AIGLX enabled
(II) Loading extension GLX
***********************************************************************

> Can you enable desktop effects or use applications which require GL
> extensions?

Under Xen - noway.

To get system working i do nothing with NVIDIA driver when use 2.6.30.1 (2.6.29.4) xenified (aka Suse) kernel. (GeForce 8500 GT). I guess nvidia
driver patched to work under Xen comes with aka Suse Kernel. That
makes  Xorg.0.log to view as it is.

Problem is  pvops kernel.  I started thread with light hope to get a feedback from someone of pvops kernel core developers. Here it goes :-

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

Wednesday, July 15, 2009 4:14 AM

From: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>

Add sender to Contacts To:"Jeremy Fitzhardinge" <jeremy@xxxxxxxx>

Cc: "Boris Derzhavets" <bderzhavets@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Michael Ralston" <michael@xxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>

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.


>In regards to the 2.6.30.1 patches, I'm a bit confused as to what
>needed to be changed in what way with the whole SPARSE_IRQ thing. I've
>talked to people on irc and I'm not alone in this confusion. Maybe you
>could blog on those changes, be a bit more verbose about which lines
>need to be changed in which way?

View:-

http://lxer.com/module/newswire/view/122758/index.html

I believe it's an exact instruction which files and where to update.

***************************************************************************
Made two replacements CONFIG_SPARSE_IRQ by CONFIG_GENERIC_HARDIRQS. View the last entries in thread [2] @ xen-devel mailing list.

In 60035_xen3-patch-2.6.29.patch1 line 11568

+#ifdef CONFIG_SPARSE_IRQ
+ irq_to_desc(irq)->kstat_irqs[cpu] = 0;
+#else
kstat_cpu(cpu).irqs[irq] = 0;

In 60036_xen3-patch-2.6.30.patch1 line 18283

+#ifdef CONFIG_SPARSE_IRQ
+int __init arch_probe_nr_irqs(void)
+{
+ int nr;
+
+ if (nr_irqs > (NR_VECTORS * nr_cpu_ids))
+ nr_irqs = NR_VECTORS * nr_cpu_ids;
****************************************************************

View also thread.

 http://www.nabble.com/2.6.30-dom0-Xen-patches-td24293721.html

and in particular posting from Jan Beulich :-

************************************************
Re: 2.6.30 dom0 Xen patches
************************************************

by Jan Beulich Jul 10, 2009; 04:52pm :: Rate this Message: - Use ratings to moderate (?)

Reply | Reply to Author | Print | View Threaded | Show Only this Message

>>> Boris Derzhavets <bderzhavets@...> 10.07.09 14:40 >>>
>I still believe in 60035_xen3-patch-2.6.29.patch1 line 11568  
>
>+#ifdef CONFIG_SPARSE_IRQ
>+                       irq_to_desc(irq)->kstat_irqs[cpu] = 0;
>+#else
>                        kstat_cpu(cpu).irqs[irq] = 0;
>
>causes a problem.

Sure - that's what I keep telling you: This needs to be replaced by
CONFIG_GENERIC_HARDIRQS in the .30 patch.

Oh, I think I now understand what you first did: You apparently replaced
the *other* +#ifdef CONFIG_SPARSE_IRQ in the .30 patch - that's wrong.
You need to make the .30 patch *additionally* make the change indicated
above. (Of course, you could do that in the .29 patch right away, but then
your .29 patch will no longer properly reflect what's needed for that version
to build and/or work right.)

Jan



>I've also been trying the pv_ops kernel with xen 3.4.1, and it's been
>freezing when I shutdown a open solaris guest.

I need your Xen and pvops setup in details to be able to respond

> I've also found that
>for some reason when I xm create a dom with soundhw specified, the
>qemu-dm logs tell me that soundhw is an invalid option with xen 3.4.1.
>For these reasons I've switched back to xen 3.3.

Wrong list. Post this issue to xen-devel mailing list.

Boris

Attachment: Xorg.0.log.tar.bz2
Description: application/bzip

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users