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


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

To: xen-users@xxxxxxxxxxxxxxxxxxx, Michael Ralston <michael@xxxxxxxxxxxxx>
Subject: [Xen-users] Re: NVIDIA, patches, PV_OPS and Xen 3.4.1
From: Boris Derzhavets <bderzhavets@xxxxxxxxx>
Date: Thu, 16 Jul 2009 23:40:42 -0700 (PDT)
Delivery-date: Thu, 16 Jul 2009 23:42:25 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247812842; bh=CdG1t6XPPRweiSlK1D2RD+lBU1IIYM8x3hIlHy2Z0c4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=knSKs7WWEi+NC1GMR1fO5tydRLIRjtqBTvHddcwC3ogTwx6GMtGFOiUWaUyj9WoXXbLZRJ5xjMYiCC0yXw6lOmCmVBd+z2cu2o0rDJE0/t8f6PEemIyhnI+wC5b2EEivdl02EIC8i4amgMLnwdDLjDeoLboPOIFpybcxT+cA0Do=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=07IXOfzL4bGEsWjtLn1Ne8iCDzIvfL1gQXL93hqih1EdmBshuqZ1EwXGp/awwCoBY3hfkedKb29yOEVDXWAKZGuaGsehss3mZ3a8tpuUO7zi1MLoZM8QvAyJlbmQ+bbzB7284aVAum+ZmOmjy7DnbBu2P+/JUkampRBCh0R0c68=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
>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 ( 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
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>
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...


>In regards to the 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?



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

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

In 60036_xen3-patch-2.6.30.patch1 line 18283

+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.


and in particular posting from Jan Beulich :-

Re: 2.6.30 dom0 Xen patchesClick to flag this post

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  
>+                       irq_to_desc(irq)->kstat_irqs[cpu] = 0;
>                        kstat_cpu(cpu).irqs[irq] = 0;
>causes a problem.

Sure - that's what I keep telling you: This needs to be replaced by

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.)


>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.


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

Xen-users mailing list