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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list