Xorg Cirrus graphics driver in KVM guest

[paradigm-X]

I have installed a Gentoo guest in KVM, which also has Gentoo host system. The system appears to run just fine in terminal mode, but I cannot yet get the X GUI to fire up. I have installed only a minimal default X environment for now until I get the GUI working properly, which I can then tweak and build into a full-blown desktop system. Anyway, I am getting an error message about the graphics driver being interferred with by a module in the kernel. The problem at this point from what I can see is that I don't know which module is creating the problem with it. I installed the Cirrus graphics driver by compiling it into the kernel, not as a module. So, when I run 'lsmod', it does not show up anywhere. Based on what I can see and know how to do right now, I cannot determine which other module would be occupying its space, as the error message from '/var/log/xorg.0.log' has indicated, which I pasted below. If anyone can point me in the right direction as to my next step along the way, I would appreciate it. Here now are the two pieces of information I can see from lspci and xorg.0.log. Below these I have also posted my monitor configuration section from '/etc/X11/xorg.conf.d/10-monitor.conf'.

------------------

error message indicated in '/var/log/xorg.0.log':

[ 27.217] ABI class: X.Org Video Driver, version 14.1
[ 27.217] (II) CIRRUS: driver for Cirrus chipsets: CLGD5430, CLGD5434-4, CLGD5434-8,
CLGD5436, CLGD5446, CLGD5480, CL-GD5462, CL-GD5464, CL-GD5464BD,
CL-GD5465, CL-GD7548, CL-GD7555, CL-GD7556
[ 27.218] (--) using VT number 7

[ 27.248] (WW) Falling back to old probe method for cirrus
[ 27.249] (--) Assigning device section with no busID to primary device
[ 27.249] (--) Chipset CLGD5446 found
[ 27.249] (EE) cirrus: The PCI device 0xb8 at 00@00:02:0 has a kernel module claiming it.
[ 27.249] (EE) cirrus: This driver cannot operate until it has been unloaded.
[ 27.249] (EE) No devices detected.
[ 27.249] (EE)
Fatal server error:
[ 27.249] (EE) no screens found(EE)
[ 27.249] (EE)

----------------

output from 'lspci -vv':

00:02.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA controller])
Subsystem: Red Hat, Inc Device 1100
Physical Slot: 2
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Region 0: Memory at fc000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at febd7000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at febc0000 [disabled] [size=64K]
Kernel driver in use: cirrus

---------

# 10-monitor.conf

Section "Monitor"
Identifier "Monitor0"
HorizSync 1.0-10000.0
VertRefresh 1.0-10000.0
EndSection

Section "Device"
Identifier "Device0"
Driver "cirrus"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
EndSection

[Logicien]

You have two Cirrus graphic options in the kernel, CONFIG_DRM_CIRRUS_QEMU is the KMS framebuffer that fit with qemu-kvm with a Cirrus virtual video card. The help say that it's only appropriate for virtualisation with the use of the modesetting Xorg video driver. So here, the use of the cirrus Xorg video driver is not what they recommand.

You have also the CONFIG_FB_CIRRUS option that is a framebuffer driver for real Cirrus graphic cards. This framebuffer driver support the Qemu Cirrus emulated graphic card, but only tests can say fi it work with.

I had Archlinux who was installed in qemu-kvm with a Cirrus virtual video card. What I remember is that the vesa Xorg video driver was working better probably with vesafb in the kernel.

So, you have to alternate the tests between a combinaison of one of the Qemu Cirrus Drm, Cirrusfb, Vesafb or Uvesafb in the kernel with one of the Cirrus, Vesa or Modesetting Xorg video driver to find which duo give the best performances.

Note, I was using the qemu -vga cirrus parameter until I read

[paradigm-X]

Currently, I have this setting in the kernel, CONFIG_DRM_CIRRUS_QEMU, which I selected because the menuconfig Help file stated that it is appropriate with Qemu, which I am using. You mentioned, "The help say that it's only appropriate for virtualisation with the use of the modesetting Xorg video driver." Which help file are you referring to here?

I did not consider using CONFIG_FB_CIRRUS option because the Xorg guide from here, "https://wiki.gentoo.org/wiki/Xorg/Configuration", advises against using all frame buffer devices:

Device Drivers --->
Graphics support --->
Support for frame buffer devices --->
## (Disable all drivers, including VGA, Intel, nVidia, and ATI)

## (Further down, enable basic console support. KMS uses this.)
Console display driver support --->
<*> Framebuffer Console Support


Do I understand you correctly in that you have in fact used, conversely, some of the frame buffer devices to good effect with KVM/Qemu guest? Again, it also sounds like you have done so when you stated, "What I remember is that the vesa Xorg video driver was working better probably with vesafb in the kernel." This option too seems to be contrary to the instructions I have found. Nevertheless, I would go ahead and try enabling frame buffer devices as I am not averse to trying it if you have found it to work under the same circumstances, but I want to be sure that I understand you correctly.

Another option I am strongly considering is to recompile the kernel with the setting CONFIG_DRM_CIRRUS_QEMU as a module instead of into the kernel so that I might then see which other module interacts with it when I do lsmod. another factor complicating the testing of different drivers is that I would need to reinstall Xorg-drivers with additional options in 'make.conf' VIDEO_CARDS. Have I understood you correctly then?

I would like to find a way of determining which module interfered with it without having to disable them one by one, but that may be a course if necessary. I really want to know if there is a way to determine what space each of the modules is occupying so that I can compare it to the space identified in the 'Xorg.0.log', but I have not yet seen a way to figure that much out. I am inclined to think that there must be a way to pinpoint the space, but I just don't have enough experience to know how.

[Logicien]

If your guest Gentoo system work just fine in console with CONFIG_DRM_CIRRUS_QEMU, this is a good point. Your problem probably come from the Xorg video driver you use, xf86-video-cirrus. The Linux kernel help about CONFIG_DRM_CIRRUS_QEMU say to use xf86-video-modesetting. So in /etc/portage/make.conf you should write

[paradigm-X]

I am utterly delighted to say that I have graphics now in the Gentoo guest. I do very much appreciate your pointers, Logicien. This is the first instance of my having to fiddle around with 'xorg.conf' and to swap out drivers just to make it work minimally. I really need to get a much better understanding of how this functionality works exactly because, for one big reason among many, I probably do not yet have the best combination of graphic devices and settings for this system. It may not be a good idea to simply settle for the first viable solution. What's more, I don't even understand the most efficient aspects of troubleshooting for this particular problem because the basic and practical inner workings of its elements are not clear enough. I would like to find among the Gentoo documentation a very practical guide aimed especially at the task of troubleshooting. The references here are numerous, but I think that they are a bit scattered, and this makes it difficult to track down relevant information on even some of the more basic topics.

It might help to explain briefly what I have done to make the display appear on this KVM/Qemu guest. After making a stage3 installation according to the Gentoo Handbook and compiling the guest's kernel based on what I found scattered about, much of it from "https://wiki.gentoo.org/wiki/Xorg/Configuration", I was expecting to get a GUI simply by typing 'startx' because this had pretty much always worked for me previously. When it failed this time, I began following the trail of leads from the messages having appeared on the terminal afterwards. I found an example configuration file for the monitor and plugged it in at '/etc/X11/xorg.conf.d/10-monitor.conf'. I posted the original earlier, but the one I now have working is this:

---------

# 10-monitor.conf

Section "Monitor"
Identifier "Monitor0"
HorizSync 1.0-10000.0
VertRefresh 1.0-10000.0
EndSection

Section "Device"
Identifier "Device0"
Driver "vesa"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
EndSection

----------------------

As you can see, I have ended up changing it to use the "vesa" driver, which is one of those you mentioned in your post, i.e., VIDEO_CARDS="cirrus modesetting vesa". Initially, I only used the "cirrus" option. After making those additional entries, I re-emerged xorg-server and world. Why was it necessary to use 'world' instead of simply xorg-server?

Also, among the driver options I saw in KVM/Qemu virt-manager, I had selected cirrus from the list, which included these: Cirrus, QXL, VMVGA, Vga, and Xen. I opted on Cirrus initially because, as I understood it, it was suggested in menuconfig as the one for Qemu guests when not using Spice viewer. I will need to figure out which of these is better for me to use as both VMVGA and Vga work similarly when I have put "vesa" as the device driver in "10-monitor.conf".

So far I have found that only when I put the "vesa" device driver in Xorg in combination with one of these two graphics cards (VMGA or Vga) can I then get an X GUI in this guest. Now it is time for me to investigate to what extent I can tweak this combination to provide a good graphic experience or to consider whether I can find a better solution with additional troubleshooting steps. My first thoughts and initial impressions are that the vesa driver is the least capable of all of them.

Nevertheless, again, thank you for the pointers along the way. At least I do have something to move forward with. Progress can be slow-going, to be sure.

[paradigm-X]

I wanted to share a follow-up point because it has made a huge improvement in the graphics. I recompiled qemu with support for Spice, and then I switched the display device from vnc to spice while leaving, for now anyway, the device driver as vesa. When I rebooted the guest, I immediately saw an improved image and the input devices seemed more responsive. It also totally eliminated the small amount of very annoying static that appeared when I moved the cursor from one window to another in the guest. So changing to this display device made a huge improvement even with the generic vesa device driver. Doing this much did not yet introduce much overhead.

Spice makes use of paravirtualization to do its magic, and it has a lot of extra functionality that can only be realized by installing its special drivers. So I have decided to go all in with it for now to see what happens. There is a Spice agent package in Gentoo for me to install and learn more about now. But I wanted to mention this much in case anyone else runs into a situation where they want options. This worked well on a Gentoo guest without a lot of prodding. Problem solved!

[paradigm-X]

Logicien, hello again. When I started this thread, I was working on a KVM/Qemu VM with Linux guest, and I have since gotten that machine working quite well in terms of graphic support by using the Spice driver and device in Qemu. Now I am working on another guest in Qemu, but this one is Windows. Actually, I will be doing a few different Windows guests, but I am going to start with what I hope will be an easier one to get set up, namely, Windows XP. I would like to start by trying to use your approach with the vesa driver in Bochs BIOS, which Qemu utilizes.

When you mentioned that point, it really did not sink in what you referred to, largely because I was just too preoccupied in a train of thought. But now that I have had a chance to review your comments, and as my curiosity, and objective, has led me to take a closer look at this website, "http://wiki.osdev.org/Bochs_VBE_Extensions", I am inclined to say that it sounds like a very sensible approach, quite so, and one that is especially applicable to my situation because I intend to have these VMs running in high resolution.

Therefore, I would like to ask you a few questions about your settings to make it happen. I don't know what you use to manage this Windows VM, but I am using virt-manager for the most part, at least initially. (After becoming more familiar with KVM/Qemu's ins-and-outs, I will start using its command line interface more often.) Either way I expect that you need to set a video device and video driver, i.e., vga. When I set these up in virt-manager, I see two options for the Display Device, VNC or Spice. What choice do you make along these lines? Are you able to access the Windows display directly on the same machine where Qemu is run, or is it a remote connection? How much video RAM have you assigned to the display when you (have to) look at Windows in high-res?

What all did you use for its setting in 'make.conf' on the line VIDEO_CARDS? Also, I may be over-working my imagination when reading the information from the website I just mentioned above, but it seems a bit unclear to me how I am supposed to go about setting the resolution and color depth. Did you merely go through a procedure similar to the one described in it, accordingly:

"To do so, disable the VBE extensions (see above), write the X resolution, Y resolution and BPP to their respective registers (VBE_DISPI_INDEX_XRES (1), VBE_DISPI_INDEX_YRES (2) and VBE_DISPI_INDEX_BPP (3)) and enable the VBE extensions."

[chithanh]

You were using the wrong driver. You need to use xf86-video-modesetting in combination with DRM_CIRRUS_QEMU, or xf86-video-qxl in combination with SPICE.

For Windows, you can download QXL drivers from the SPICE website.

[paradigm-X]

> "You need to use xf86-video-modesetting in combination with DRM_CIRRUS_QEMU, or xf86-video-qxl in combination with SPICE."

Hello, chithanh. Thanks for chiming in on this discussion. I welcome your input here. I did eventually discover the right combination of settings, drivers and whatnot to use with the Spice solution, and I got it working nicely on the VM with a Linux guest. It rocks! As for the xf86-video-modesetting driver, yours was the first mentioning of it I have seen. I will give it a try shortly just as soon as I get to a point where I can stop what I am doing on that machine right now.

Meanwhile, however, this leads me to make a point about the general lack of good, obvious information presently available in relation to the configurations required for properly running X environments, not just in Qemu but also in vanilla setups directly on hardware. No one in particular is responsible for this state of affairs, and certainly I don't mean this comment to be a complaint aimed at Gentoo support channels. (I think Gentoo is a truly marvelous Linux distribution, and its Handbook is arguably one of the best tools around to support its users. Its developers are excellent and second to none. There is an abundance of materials and tools to help in security and a number of other important areas of concern and interest. Yet, from what I have seen, there is one critically important area where it appears to be quite inadequate, either that or I have just totally overlooked a big part of its offerings. That is, in the matter of good material for getting X installed and tweaked, much more basic work is needed. There now, I have stated my two cents worth.

Where did you find the information about which drivers to use for cirrus and for the others in general? I do not see it even mentioned, or linked to, in what would seem like the most natural places for doing so:

https://wiki.gentoo.org/wiki/Xorg/Configuration
http://wiki.gentoo.org/wiki/QEMU/Options

Finally, let me ask you about a procedure in regard to installing new drivers for use with Xorg-server. When we install a new driver like xf86-video-modesetting and switch the corresponding display settings to Cirrus, what all then needs to be rebuilt before they can be used in X? Is it then sufficient to re-emerge xorg-server, or should other programs be redone too, such as mesa or another? What do you redo in your settings after adding new drivers? Do you always remove the previous driver beforehand as well? Thanks, again, for the input, chithanh.

[chithanh]

The modesetting driver was already mentioned in Logicien's first reply.

When you update VIDEO_CARDS in make.conf you can optionally rebuild xorg-drivers so it pulls in the new package. It is not necessary to remove any driver except for debugging purposes. The X server will just try a built-in list of drivers until one loads successfully.

About the cirrus driver being incompatible with the KMS driver for QEMU, I think it was mentioned in the release announcement.