Fwd: [Xen-devel] Has Anyone Been Able to Run PVOPS DomU Against any nVidia Chipset?

[John McDermott (U.S. Navy Employee) <john.mcdermott@xxxxxxxxxxxx>]

sorry, forgot to reply all ...

Begin forwarded message:

> From: "John McDermott (U.S. Navy Employee)" <john.mcdermott@xxxxxxxxxxxx>
> Date: September 17, 2010 2:57:59 PM EDT
> To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Subject: Re: [Xen-devel] Has Anyone Been Able to Run PVOPS DomU Against any 
> nVidia Chipset?
> 
> Jeremy,
> 
> Thanks. I will probable build a new development system that has an on-board 
> Matrox chipset. Meanwhile, I willing to keep pounding on this hardware to see 
> what is causing the problem. I have a tarball of the serial output, lspci, 
> .config etc., from the i7 machine, if that would be of any help.
> 
> On Sep 17, 2010, at 2:35 PM, Jeremy Fitzhardinge wrote:
> 
>> On 09/17/2010 09:53 AM, John McDermott (U.S. Navy Employee) wrote:
>>> Xen Developers,
>>> 
>>> This has already been posted to Xen-Users, but  I got no response.
>>> 
>>> Short version: has anyone been able to run a 2.6.32.18 PVOPS domU, on Xen 
>>> 4.0.1, on Fedora 13, against any nVidia chipset? I'd like to know which 
>>> chipset please.
>> 
>> By "nVidia chipset" do you mean a system chipset, or specifically a
>> graphics card?
> 
> @Jeremy, both the boxes have graphics cards made by nVidia, but as far as I 
> can tell the issue is the chipset on the card.
>> 
>> By "run ... pvops domU ... against any nVidia chipset" do you mean
>> passing the hardware through to the domU?
> 
> @Jeremy, no passthrough.
>> 
>> Are you running domU as HVM or PV?  If it is HVM, are you using stubdoms?
> 
> @Jeremy, I have tried both HVM and PV domU; no stubdoms. Basically, I just 
> followed the directions Boris D. has on his blog, which seem to work fine 
> until things get to domU video time.
>> 
>>> Long version:
>>> 
>>> I have encountered what appears to be an interesting video or DRM problem 
>>> with this combination.   Dom0 runs X11 without problems but this 
>>> combination will not run X11 as dom U. While attempting to install Fedora 
>>> 13 dom U as an HVM, using a 2.6.32.18 PVOPS dom0, running on Xen 4.0.1 on 
>>> Fedora 13,  using virt-install --nographics, it reaches the point following 
>>> the XML display of the boot guest configuration, reports an
>>> 
>>> (EE) FBDEV(0): FBIOBLANK: Invalid argument
>>> 
>>> error and then hangs with garbage displayed on my remote xterm console. 
>>> (Virt-install --vnc dies also.) My serial console shows a bunch of 
>>> hypervisor
>>> 
>>> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
>>> ...
>>> 
>>> and then some
>>> 
>>> ...
>>> (XEN) vlapic.c:702:d2 Local APIC Write to read-only register 0x30
>>> 
>>> error messages.
>> 
>> I think those are more warnings than errors.  Are there any other error
>> messages?
> 
> @ Jeremy, not from Xen and all of the other errors are X11 errors. My xterm 
> just goes to garbage when I try to virt-install an HVM.
>> 
>>> I can get a pvops domain U to install --nographics, but the resulting guest 
>>> cannot start X and fails with the same "(EE) FBDEV(0): FBIOBLANK: Invalid 
>>> argument". No hypervisor error messages are generated by this failure.
>> 
>> If you're using an emulated FB then it should Just Work, and be
>> independent of whatever the host graphics chip is - and emulated is
>> probably what you should be using for install regardless of what you
>> plan to do once the guest is installed.
> 
> @Jeremy, that is what I expected; that is why I posted when it did not; it 
> surprised me. In my admittedly dated experience with fighting nVidia on Linux 
> since about 1998, nVidia just makes awkward things happen. All of my recent 
> coding experience is in the hypervisor code, which is where our research is 
> focused. So I am a noob about modern Linux kernels and hope they just work. 
> 
>> 
>> If you are passing through a graphics controller, how are you making
>> sure that dom0 isn't also using it?
> 
> @Jeremy, not passing through.
>> 
>>> I have tried to get this kernel-hypervisor combination working on 2 
>>> different boxes:
>>> 
>>> 1)  a Dell Precision 690 with an Intel E6320 processor (I don't think this 
>>> is the issue) and an nVidia Quadro NVS 285, which X11 reports as nVidia NV 
>>> 44. Plain old Fedora 13 uses the nouveau driver with no problems. Udev 
>>> tells me it is version 153. The problem remains even with the kernel booted 
>>> nopat.
>>> 
>>> 2) a "roll-your-own" with EVGA X58 SLI motherboard / Intel i7 combination, 
>>> with an nVidia GEForce 9800 GTX+, which X11 reports as nVidia G92. Again, 
>>> plain old Fedora 13 uses the nouveau driver for this, without problems. 
>>> Trying a pvops domU gives me the same behavior: Fedora domU installs and 
>>> runs fine, but cannot start X11.
>>> 
>>> I have tried this against 2 kernels: Jeremy's e6b92c and Michael Young's 
>>> 2.6.32.21-167.xendom0.fc13.x86_64. (The latter fails in video during kernel 
>>> boot, when I use init=/sbin/upstart, but boots OK without it, but then 
>>> fails to run X on domU's.) When building these kernels, both complain about 
>>> missing the nouveau module at depmod time.
>>> 
>>> Before I go swapping cards or outright buying one, has anyone run this 
>>> pvops combination against any nVidia-based graphics card? Does pvops 
>>> require an ATI chipset?
>> 
>> Konrad has done a lot of work on making many different graphics cards
>> work, including nVidia, at least in dom0.
> 
> @Jeremy, the nVidia stuff runs great in the pvops dom0 on both of my boxes. 
> Using the nv driver I think?
>> 
>>> Has pvops been run against an onboard Matrox chipset, as on a server?
>> 
>> Yes, my home server machine has a Matrox controller which works OK.
>> 
>>   J
> 
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
> 
> J.P. McDermott                                building 12
> Code 5542                                     mcdermott@xxxxxxxxxxxxxxxx
> Naval Research Laboratory     voice: +1 202.404.8301
> Washington, DC 20375, US      fax:   +1 202.404.7942
> 
> 
> 
> 
> 
> 
> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott                          building 12
Code 5542                                       mcdermott@xxxxxxxxxxxxxxxx
Naval Research Laboratory       voice: +1 202.404.8301
Washington, DC 20375, US        fax:   +1 202.404.7942








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