[libvirt] unsupported configuration: unknown video model 'virtio' - virtio-vga

poma pomidorabelisima at gmail.com
Fri Aug 7 09:20:33 UTC 2015


On 29.07.2015 18:28, Daniel P. Berrange wrote:
> On Mon, Jul 20, 2015 at 03:38:59PM +0200, Martin Kletzander wrote:
>> On Mon, Jul 20, 2015 at 11:23:02AM +0200, poma wrote:
>>>
>>> $ qemu-system-x86_64 ... -device virtio-vga
>>>
>>>
>>> # lspci -d 1af4:1050 -knn
>>> 00:03.0 VGA compatible controller [0300]: Red Hat, Inc Device [1af4:1050] (rev 01)
>>> 	Subsystem: Red Hat, Inc Device [1af4:1100]
>>> 	Kernel driver in use: virtio-pci
>>> 	Kernel modules: virtio_pci
>>>
>>>
>>> # dmesg | grep virtio
>>> [    1.727390] [drm] pci: virtio-vga detected
>>> [    1.729315] [drm] virtio vbuffers: 80 bufs, 192B each, 15kB total.
>>> [    2.023845] virtio_gpu virtio0: fb0: virtiodrmfb frame buffer device
>>> [    2.023846] virtio_gpu virtio0: registered panic notifier
>>> [    2.043135] [drm] Initialized virtio_gpu 0.0.1 0 on minor 0
>>>
>>>
>>> # journalctl -b -u libvirtd.service -o cat
>>> Starting Virtualization daemon...
>>> Started Virtualization daemon.
>>> libvirt version: 1.2.17, package: 1.fc23 (Fedora Project, 2015-07-14-18:18:48, buildvm-03.phx2.fedoraproject.org)
>>> unsupported configuration: unknown video model 'virtio'
>>>
>>
>> I'm guessing you are posting all these outputs from one machine,
>> right?  Then that doesn't make sense.  I think the error from libvirt
>> is because you have a domain with invalid XML in
>> /etc/libvirt/... where you should *NOT* touch it
> 
> I think they are actually attempting to ask whether libvirt supports
> the new virtio-vga video device for QEMU yet....which we do not. We
> should add that support...
> 
> Regards,
> Daniel
> 


Daniel, exactly!

Martin, indeed, it makes sense,
let me show ...


virtio-gpu: mask as -device VGA

Newer libvirt versions start looking up VGA in the QOM tree.
So tricking libvirt this way ...

    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=virtio-vga'/>

... to test virtio-vga stopped working.

Lets rename VGA to stdvga and virtio-vga to VGA to get things going
again.  A simple ...

      <model type='vga' vram='16384' heads='1'/>

... will give you virtio-vga when building qemu with this patch applied.

---
 hw/display/vga-pci.c    | 2 +-
 hw/display/virtio-vga.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c
index 1dfa331..1a98148 100644
--- a/hw/display/vga-pci.c
+++ b/hw/display/vga-pci.c
@@ -363,7 +363,7 @@ static void secondary_class_init(ObjectClass *klass, void *data)
 }
 
 static const TypeInfo vga_info = {
-    .name          = "VGA",
+    .name          = "stdvga",
     .parent        = TYPE_PCI_VGA,
     .instance_init = pci_std_vga_init,
     .class_init    = vga_class_init,
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index f7e539f..1260011 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -7,7 +7,7 @@
 /*
  * virtio-vga: This extends VirtioPCIProxy.
  */
-#define TYPE_VIRTIO_VGA "virtio-vga"
+#define TYPE_VIRTIO_VGA "VGA"
 #define VIRTIO_VGA(obj) \
         OBJECT_CHECK(VirtIOVGA, (obj), TYPE_VIRTIO_VGA)
 
@@ -15,6 +15,7 @@ typedef struct VirtIOVGA {
     VirtIOPCIProxy parent_obj;
     VirtIOGPU      vdev;
     VGACommonState vga;
+    uint32_t       dummy;
     MemoryRegion   vga_mrs[3];
 } VirtIOVGA;
 
@@ -139,6 +140,7 @@ static void virtio_vga_reset(DeviceState *dev)
 
 static Property virtio_vga_properties[] = {
     DEFINE_VIRTIO_GPU_PCI_PROPERTIES(VirtIOPCIProxy),
+    DEFINE_PROP_UINT32("vgamem_mb", VirtIOVGA, dummy, 16),
     DEFINE_PROP_END_OF_LIST(),
 };
 

Ref.
https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg02917.html


# grep vga /etc/libvirt/qemu/Rawhide.xml
      <model type='vga' vram='16384' heads='1'/>


# lspci -d 1af4:1050 -knn
00:02.0 VGA compatible controller [0300]: Red Hat, Inc Device [1af4:1050] (rev 01)
        Subsystem: Red Hat, Inc Device [1af4:1100]
        Kernel driver in use: virtio-pci
        Kernel modules: virtio_pci


# dmesg -t | egrep -i vga\|drm
vgaarb: setting as boot device: PCI:0000:00:02.0
vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:02.0
fb0: VESA VGA frame buffer device
[drm] Initialized drm 1.1.0 20060810
[drm] pci: virtio-vga detected
fb: switching to virtiodrmfb from VESA VGA 
[drm] virtio vbuffers: 80 bufs, 192B each, 15kB total.
virtio_gpu virtio0: fb0: virtiodrmfb frame buffer device
[drm] Initialized virtio_gpu 0.0.1 0 on minor 0


# grep modeset /var/log/Xorg.0.log | grep -v Modeline
[   110.191] (==) Matched modesetting as autoconfigured driver 0
[   110.191] (II) LoadModule: "modesetting"
[   110.191] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
[   110.191] (II) Module modesetting: vendor="X.Org Foundation"
[   110.192] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   110.192] (II) modeset(0): using drv /dev/dri/card0
[   110.192] (II) modeset(0): Creating default Display subsection in Screen section
[   110.192] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[   110.192] (==) modeset(0): RGB weight 888
[   110.192] (==) modeset(0): Default visual is TrueColor
[   110.212] (EE) modeset(0): glamor initialization failed
[   110.212] (II) modeset(0): ShadowFB: preferred NO, enabled NO
[   110.212] (II) modeset(0): Output Virtual-0 has no monitor section
[   110.212] (II) modeset(0): EDID for output Virtual-0
[   110.212] (II) modeset(0): Printing probed modes for output Virtual-0
[   110.212] (II) modeset(0): Output Virtual-0 connected
[   110.212] (II) modeset(0): Using exact sizes for initial modes
[   110.212] (II) modeset(0): Output Virtual-0 using initial mode 1904x889 +0+0
[   110.212] (II) modeset(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   110.212] (==) modeset(0): DPI set to (96, 96)
[   110.216] (==) modeset(0): Backing store enabled
[   110.216] (==) modeset(0): Silken mouse enabled
[   110.216] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   110.216] (==) modeset(0): DPMS enabled
[   110.225] (II) modeset(0): Damage tracking initialized



Beside mouse cursor icon change problem - retention,
the only major inconvenience - dynamic guest resizing is broken, just as with qxl.

With the bochs vga, resizing works OK per se, that is, without the need for additional "glue" in window manager.


# lspci -d 1234:1111 -knn
00:02.0 VGA compatible controller [0300]: Device [1234:1111] (rev 02)
        Subsystem: Red Hat, Inc Device [1af4:1100]
        Kernel driver in use: bochs-drm
        Kernel modules: bochs_drm


# grep stride /var/log/Xorg.0.log
[    27.333] (II) modeset(0): Allocate new frame buffer 1920x896 stride
[   467.368] (II) modeset(0): Allocate new frame buffer 1632x902 stride
[   471.363] (II) modeset(0): Allocate new frame buffer 1704x938 stride
[   535.373] (II) modeset(0): Allocate new frame buffer 952x710 stride
[   540.368] (II) modeset(0): Allocate new frame buffer 552x818 stride
[   546.380] (II) modeset(0): Allocate new frame buffer 952x455 stride
[   554.374] (II) modeset(0): Allocate new frame buffer 424x200 stride
[   561.360] (II) modeset(0): Allocate new frame buffer 424x402 stride
[   564.357] (II) modeset(0): Allocate new frame buffer 880x402 stride
[   573.376] (II) modeset(0): Allocate new frame buffer 424x240 stride
[   576.366] (II) modeset(0): Allocate new frame buffer 792x519 stride
[   582.361] (II) modeset(0): Allocate new frame buffer 1104x608 stride
[   593.379] (II) modeset(0): Allocate new frame buffer 424x608 stride
[   604.373] (II) modeset(0): Allocate new frame buffer 424x263 stride
[   613.359] (II) modeset(0): Allocate new frame buffer 424x615 stride
[   616.358] (II) modeset(0): Allocate new frame buffer 1016x784 stride
[   624.356] (II) modeset(0): Allocate new frame buffer 1536x850 stride
[   629.362] (II) modeset(0): Allocate new frame buffer 1904x938 stride
[   636.377] (II) modeset(0): Allocate new frame buffer 1920x896 stride

# rpm -q qemu libvirt
qemu-2.4.0-0.3.rc4.fc24.x86_64
libvirt-1.2.18-1.fc24.x86_64


The question was, when we will be able to use the Virtio GPU without patched QEMU.




More information about the libvir-list mailing list