2:30 a.m.
Most of QEMU's PCI display device models, such as:
libvirt video/model/@type QEMU -device
------------------------- ------------
cirrus cirrus-vga
vga VGA
qxl qxl-vga
virtio virtio-vga
come with a linear framebuffer (sometimes called "VGA compatibility
framebuffer"). This linear framebuffer lives in one of the PCI device's
MMIO BARs, and allows guest code (primarily: firmware drivers, and
non-accelerated OS drivers) to display graphics with direct memory access.
Due to architectural reasons on aarch64/KVM hosts, this kind of
framebuffer doesn't / can't work in
qemu-system-(arm|aarch64) -M virt
machines. Cache coherency issues guarantee a corrupted / unusable display.
The problem has been researched by several people, including kvm-arm
maintainers, and it's been decided that the best way (practically the only
way) to have boot time graphics for such guests is to consolidate on
QEMU's "virtio-gpu-pci" device.
From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>;,
libvirt
supports
<devices>
<video>
<model type='virtio'/>
</video>
</devices>
but libvirt unconditionally maps @type='virtio' to QEMU's
"virtio-vga"
device model. (See the qemuBuildDeviceVideoStr() function and the
"qemuDeviceVideo" enum impl.)
According to the above, this is not right for the "virt" machine type; the
qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
virtio device without a compatibility framebuffer, is available, and works
fine.
(The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
for "virt" -- supports "virtio-gpu-pci", as of upstream commit
3ef3209d3028. See
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)
Override the default mapping of "virtio", from "virtio-vga" to
"virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.
Cc: Andrea Bolognani <abologna(a)redhat.com>
Cc: Drew Jones <drjones(a)redhat.com>
Cc: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Cc: Martin Kletzander <mkletzan(a)redhat.com>
Suggested-by: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
Acked-by: Martin Kletzander <mkletzan(a)redhat.com>
---
Notes:
v2:
- rewrap "qemuxml2argv-aarch64-video-virtio-gpu-pci.args" with
"test-wrap-argv.pl" [Martin]
- pick up Martin's ACK
src/qemu/qemu_command.c | 4 ++
tests/qemuxml2argvtest.c | 5 +++
tests/qemuxml2xmltest.c | 5 +++
tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.args | 26
+++++++++++
tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.xml | 36
++++++++++++++++
tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml | 45
++++++++++++++++++++
6 files changed, 121 insertions(+)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3a61863b9abb..038c38f2217c 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4325,6 +4325,10 @@ qemuBuildDeviceVideoStr(const virDomainDef *def,
virDomainVideoTypeToString(video->type));
goto error;
}
+ if (video->type == VIR_DOMAIN_VIDEO_TYPE_VIRTIO &&
+ qemuDomainMachineIsVirt(def)) {
+ model = "virtio-gpu-pci";
+ }
} else {
if (video->type != VIR_DOMAIN_VIDEO_TYPE_QXL) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index dbb0e4d56142..e8540779a4b5 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1872,6 +1872,11 @@ mymain(void)
QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_OBJECT_GPEX, QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE, QEMU_CAPS_VIRTIO_SCSI);
+ DO_TEST("aarch64-video-virtio-gpu-pci",
+ QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_OBJECT_GPEX,
+ QEMU_CAPS_DEVICE_PCI_BRIDGE, QEMU_CAPS_DEVICE_IOH3420,
+ QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
+ QEMU_CAPS_DEVICE_VIRTIO_GPU, QEMU_CAPS_BOOTINDEX);
DO_TEST("aarch64-aavmf-virtio-mmio",
QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_DTB,
QEMU_CAPS_DEVICE_VIRTIO_MMIO,
diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
index 14c2b0ccf2ce..fb05c8571411 100644
--- a/tests/qemuxml2xmltest.c
+++ b/tests/qemuxml2xmltest.c
@@ -831,6 +831,11 @@ mymain(void)
QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM,
QEMU_CAPS_OBJECT_GPEX, QEMU_CAPS_DEVICE_PCI_BRIDGE,
QEMU_CAPS_DEVICE_DMI_TO_PCI_BRIDGE, QEMU_CAPS_VIRTIO_SCSI);
+ DO_TEST("aarch64-video-virtio-gpu-pci",
+ QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_OBJECT_GPEX,
+ QEMU_CAPS_DEVICE_PCI_BRIDGE, QEMU_CAPS_DEVICE_IOH3420,
+ QEMU_CAPS_PCI_MULTIFUNCTION, QEMU_CAPS_DEVICE_VIDEO_PRIMARY,
+ QEMU_CAPS_DEVICE_VIRTIO_GPU, QEMU_CAPS_BOOTINDEX);
DO_TEST_FULL("aarch64-gic-none", WHEN_BOTH, GIC_NONE, NONE);
DO_TEST_FULL("aarch64-gic-none-v2", WHEN_BOTH, GIC_V2, NONE);
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.args
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.args
new file mode 100644
index 000000000000..76ee977a3ca2
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.args
@@ -0,0 +1,26 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUDIO_DRV=none \
+/opt/qemu-installed/bin/qemu-system-aarch64 \
+-name aarch64-vgpu \
+-S \
+-M virt \
+-cpu cortex-a57 \
+-m 1024 \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid f3197c89-6457-44fe-b26d-897090ba6541 \
+-nographic \
+-nodefconfig \
+-nodefaults \
+-monitor unix:/tmp/lib/domain--1-aarch64-vgpu/monitor.sock,server,nowait \
+-device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,\
+addr=0x1 \
+-device ioh3420,port=0x9,chassis=2,id=pci.2,bus=pcie.0,multifunction=on,\
+addr=0x1.0x1 \
+-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:73:34:53,bus=pci.1,addr=0x0,\
+bootindex=1 \
+-net user,vlan=0,name=hostnet0 \
+-device virtio-gpu-pci,id=video0,bus=pci.2,addr=0x0
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.xml
b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.xml
new file mode 100644
index 000000000000..4b52a731b043
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-video-virtio-gpu-pci.xml
@@ -0,0 +1,36 @@
+<domain type='qemu'>
+ <name>aarch64-vgpu</name>
+ <uuid>f3197c89-6457-44fe-b26d-897090ba6541</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <currentMemory unit='KiB'>1048576</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='aarch64' machine='virt'>hvm</type>
+ </os>
+ <features>
+ <acpi/>
+ </features>
+ <cpu mode='custom' match='exact'>
+ <model fallback='allow'>cortex-a57</model>
+ </cpu>
+ <devices>
+ <emulator>/opt/qemu-installed/bin/qemu-system-aarch64</emulator>
+ <controller type='pci' index='0' model='pcie-root'/>
+ <controller type='pci' index='1'
model='pcie-root-port'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x0' multifunction='on'/>
+ </controller>
+ <controller type='pci' index='2'
model='pcie-root-port'>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x1' multifunction='on'/>
+ </controller>
+ <interface type='user'>
+ <mac address='52:54:00:73:34:53'/>
+ <model type='virtio'/>
+ <boot order='1'/>
+ <address type='pci' domain='0x0000' bus='0x01'
slot='0x00' function='0x0'/>
+ </interface>
+ <video>
+ <model type='virtio'/>
+ <address type='pci' domain='0x0000' bus='0x02'
slot='0x00' function='0x0'/>
+ </video>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml
b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml
new file mode 100644
index 000000000000..26f6a51622ef
--- /dev/null
+++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml
@@ -0,0 +1,45 @@
+<domain type='qemu'>
+ <name>aarch64-vgpu</name>
+ <uuid>f3197c89-6457-44fe-b26d-897090ba6541</uuid>
+ <memory unit='KiB'>1048576</memory>
+ <currentMemory unit='KiB'>1048576</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='aarch64' machine='virt'>hvm</type>
+ </os>
+ <features>
+ <acpi/>
+ <gic version='2'/>
+ </features>
+ <cpu mode='custom' match='exact'>
+ <model fallback='allow'>cortex-a57</model>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/opt/qemu-installed/bin/qemu-system-aarch64</emulator>
+ <controller type='pci' index='0' model='pcie-root'/>
+ <controller type='pci' index='1'
model='pcie-root-port'>
+ <model name='ioh3420'/>
+ <target chassis='1' port='0x8'/>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x0' multifunction='on'/>
+ </controller>
+ <controller type='pci' index='2'
model='pcie-root-port'>
+ <model name='ioh3420'/>
+ <target chassis='2' port='0x9'/>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x1' multifunction='on'/>
+ </controller>
+ <interface type='user'>
+ <mac address='52:54:00:73:34:53'/>
+ <model type='virtio'/>
+ <boot order='1'/>
+ <address type='pci' domain='0x0000' bus='0x01'
slot='0x00' function='0x0'/>
+ </interface>
+ <video>
+ <model type='virtio' heads='1' primary='yes'/>
+ <address type='pci' domain='0x0000' bus='0x02'
slot='0x00' function='0x0'/>
+ </video>
+ </devices>
+</domain>
--
2.9.2
8:06 a.m.
On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
> Most of QEMU's PCI display device models, such as:
Pushed, thanks.
Ouch, you were too fast! ;)
There is something I wanted to clarify with Laszlo: is
virtio-gpu-pci ever going to be usable on other architectures
such as x86_64? Maybe it already is? Because if that's the
case, we'll want to be able to choose between virtio-vga and
virtio-gpu-pci.
One solution would be to keep mapping model='virtio' to
virtio-vga and create a new model='virtio-gpu' that maps to
virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
model='virtio'. Or something like that, I'm not married to
the idea, I just think it's something we should definitely
think about before this ends up in a release.
--
Andrea Bolognani / Red Hat / Virtualization
8:20 a.m.
On Fri, Sep 16, 2016 at 03:06:18PM +0200, Andrea Bolognani wrote:
On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
> On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
> > Most of QEMU's PCI display device models, such as:
>
> Pushed, thanks.
Ouch, you were too fast! ;)
There is something I wanted to clarify with Laszlo: is
virtio-gpu-pci ever going to be usable on other architectures
such as x86_64? Maybe it already is? Because if that's the
case, we'll want to be able to choose between virtio-vga and
virtio-gpu-pci.
One solution would be to keep mapping model='virtio' to
virtio-vga and create a new model='virtio-gpu' that maps to
virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
model='virtio'. Or something like that, I'm not married to
the idea, I just think it's something we should definitely
think about before this ends up in a release.
I have some patches in my TODO branch that will rewrite the video
device code. virtio-gpu-pci is usable also on other architectures
but it lacks the VGA compatibility mode. In libvirt all primary
video devices for x86 architecture have VGA mode. Currently we
allow only QXL to be used as secondary video device and now with
the virtio-gpu-pci it could be also used as secondary video device.
The solution would be simple, there is no need to add a new video
model 'virtio-gpu', we will use the existing model 'virtio', but
depending on architecture and also whether it's primary or
secondary video device we will use appropriate device.
We already do this for QXL.
Pavel
8:32 a.m.
On Fri, Sep 16, 2016 at 03:20:16PM +0200, Pavel Hrdina wrote:
On Fri, Sep 16, 2016 at 03:06:18PM +0200, Andrea Bolognani wrote:
> On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
> > On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
> > > Most of QEMU's PCI display device models, such as:
> >
> > Pushed, thanks.
>
> Ouch, you were too fast! ;)
>
> There is something I wanted to clarify with Laszlo: is
> virtio-gpu-pci ever going to be usable on other architectures
> such as x86_64? Maybe it already is? Because if that's the
> case, we'll want to be able to choose between virtio-vga and
> virtio-gpu-pci.
>
> One solution would be to keep mapping model='virtio' to
> virtio-vga and create a new model='virtio-gpu' that maps to
> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
> model='virtio'. Or something like that, I'm not married to
> the idea, I just think it's something we should definitely
> think about before this ends up in a release.
I have some patches in my TODO branch that will rewrite the video
device code. virtio-gpu-pci is usable also on other architectures
but it lacks the VGA compatibility mode. In libvirt all primary
video devices for x86 architecture have VGA mode. Currently we
allow only QXL to be used as secondary video device and now with
the virtio-gpu-pci it could be also used as secondary video device.
The solution would be simple, there is no need to add a new video
model 'virtio-gpu', we will use the existing model 'virtio', but
depending on architecture and also whether it's primary or
secondary video device we will use appropriate device.
We already do this for QXL.
I'm not sure we're on the same track, so just to confirm I'll ask few
questions. We guarantee that on x86_64 primary video devices have
always VGA compatibility mode? So virtio-gpu-pci will *never* be able
to act as a primary video on x64? If the answers are "yes, yes", then I
think this patch can stay as it is. Unless I missed something else.
Pavel
8:41 a.m.
On Fri, Sep 16, 2016 at 03:32:59PM +0200, Martin Kletzander wrote:
On Fri, Sep 16, 2016 at 03:20:16PM +0200, Pavel Hrdina wrote:
>On Fri, Sep 16, 2016 at 03:06:18PM +0200, Andrea Bolognani wrote:
>> On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
>> > On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
>> > > Most of QEMU's PCI display device models, such as:
>> >
>> > Pushed, thanks.
>>
>> Ouch, you were too fast! ;)
>>
>> There is something I wanted to clarify with Laszlo: is
>> virtio-gpu-pci ever going to be usable on other architectures
>> such as x86_64? Maybe it already is? Because if that's the
>> case, we'll want to be able to choose between virtio-vga and
>> virtio-gpu-pci.
>>
>> One solution would be to keep mapping model='virtio' to
>> virtio-vga and create a new model='virtio-gpu' that maps to
>> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
>> model='virtio'. Or something like that, I'm not married to
>> the idea, I just think it's something we should definitely
>> think about before this ends up in a release.
>
>I have some patches in my TODO branch that will rewrite the video
>device code. virtio-gpu-pci is usable also on other architectures
>but it lacks the VGA compatibility mode. In libvirt all primary
>video devices for x86 architecture have VGA mode. Currently we
>allow only QXL to be used as secondary video device and now with
>the virtio-gpu-pci it could be also used as secondary video device.
>
>The solution would be simple, there is no need to add a new video
>model 'virtio-gpu', we will use the existing model 'virtio', but
>depending on architecture and also whether it's primary or
>secondary video device we will use appropriate device.
>We already do this for QXL.
>
I'm not sure we're on the same track, so just to confirm I'll ask few
questions. We guarantee that on x86_64 primary video devices have
always VGA compatibility mode? So virtio-gpu-pci will *never* be able
to act as a primary video on x64? If the answers are "yes, yes", then I
think this patch can stay as it is. Unless I missed something else.
The answer is yes. This patch is correct, fixes things on aarch64
and doesn't break anything on x64.
Pavel
10:12 a.m.
On 09/16/16 15:32, Martin Kletzander wrote:
On Fri, Sep 16, 2016 at 03:20:16PM +0200, Pavel Hrdina wrote:
> On Fri, Sep 16, 2016 at 03:06:18PM +0200, Andrea Bolognani wrote:
>> On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
>> > On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
>> > > Most of QEMU's PCI display device models, such as:
>> >
>> > Pushed, thanks.
>>
>> Ouch, you were too fast! ;)
>>
>> There is something I wanted to clarify with Laszlo: is
>> virtio-gpu-pci ever going to be usable on other architectures
>> such as x86_64? Maybe it already is? Because if that's the
>> case, we'll want to be able to choose between virtio-vga and
>> virtio-gpu-pci.
>>
>> One solution would be to keep mapping model='virtio' to
>> virtio-vga and create a new model='virtio-gpu' that maps to
>> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
>> model='virtio'. Or something like that, I'm not married to
>> the idea, I just think it's something we should definitely
>> think about before this ends up in a release.
>
> I have some patches in my TODO branch that will rewrite the video
> device code. virtio-gpu-pci is usable also on other architectures
> but it lacks the VGA compatibility mode. In libvirt all primary
> video devices for x86 architecture have VGA mode. Currently we
> allow only QXL to be used as secondary video device and now with
> the virtio-gpu-pci it could be also used as secondary video device.
>
> The solution would be simple, there is no need to add a new video
> model 'virtio-gpu', we will use the existing model 'virtio', but
> depending on architecture and also whether it's primary or
> secondary video device we will use appropriate device.
> We already do this for QXL.
>
I'm not sure we're on the same track, so just to confirm I'll ask few
questions.
I'm not sure if you are asking me :), but I'll answer anyway :)
We guarantee that on x86_64 primary video devices have
always VGA compatibility mode?
Yes.
So virtio-gpu-pci will *never* be able
to act as a primary video on x64?
I wouldn't put it this way. Dependent on your firmware and on your guest
OS, virtio-gpu-pci *can* act as a primary video card on x86_64 too, but:
- some guest OSes (notably UEFI Windows) will be plain unable to work
with it,
- even with other OSes (for example, UEFI Linux), virtio-gpu-pci will
work, but the functionality that you will get with virtio-gpu-pci in
both the firmware and in the OS will be somewhat limited related to the
virtio-vga feature set. Namely, in UEFI you will only get a
GRAPHICS_OUTPUT_PROTOCOL that only supports Blt(), no direct framebuffer
access -- and some UEFI applications / boot loaders might insist on
framebuffer access --, plus in Linux, until the virtio-gpu driver kicks
in and you get "virtiodrmfb" fired up, you will have an initial window
in time where the graphics display doesn't work for simple text output
even. (In more technical terms, the "efifb" driver has no chance of
working, until the virtio-gpu drmfb driver supplants it, because efifb
also depends on framebuffer access).
So, while virtio-gpu-pci *could* work on x86_64 as a primary graphics
card, you really don't want it, because virtio-vga is just better.
In aarch64/KVM guests, the choice is however between "somewhat limited,
with virtio-gpu-pci" and "completely non-functional".
Using a graphics card as primary that was originally designed as
secondary is quite unusual for a number of programs; this is why I had
to send a patch for Xorg/Xserver too (the card wouldn't be picked up
automatically otherwise, as primary). This is simply how video tends to
work on aarch64, even on phys hardware; the Xorg/Xserver patch in
question happened to solve the identical problem for Marcin's physical
Mustang + Radeon setup.
If the answers are "yes, yes", then I
think this patch can stay as it is. Unless I missed something else.
The answer is "practically yes". Virtio-gpu-pci *could* act as a
(limited) primary video device in x86_64 guests, but due to those
limitations (whose annoyances vary across guest OSes) you really
wouldn't want to pick virtio-gpu-pci as primary there.
Thanks
Laszlo
8:44 a.m.
On Fri, 2016-09-16 at 15:20 +0200, Pavel Hrdina wrote:
> There is something I wanted to clarify with Laszlo: is
> virtio-gpu-pci ever going to be usable on other architectures
> such as x86_64? Maybe it already is? Because if that's the
> case, we'll want to be able to choose between virtio-vga and
> virtio-gpu-pci.
>
> One solution would be to keep mapping model='virtio' to
> virtio-vga and create a new model='virtio-gpu' that maps to
> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
> model='virtio'. Or something like that, I'm not married to
> the idea, I just think it's something we should definitely
> think about before this ends up in a release.
I have some patches in my TODO branch that will rewrite the video
device code. virtio-gpu-pci is usable also on other architectures
but it lacks the VGA compatibility mode. In libvirt all primary
video devices for x86 architecture have VGA mode. Currently we
allow only QXL to be used as secondary video device and now with
the virtio-gpu-pci it could be also used as secondary video device.
The solution would be simple, there is no need to add a new video
model 'virtio-gpu', we will use the existing model 'virtio', but
depending on architecture and also whether it's primary or
secondary video device we will use appropriate device.
We already do this for QXL.
I don't know much about video devices, so forgive me if I'm
asking silly questions, but what is preventing you (on x86)
from having virtio-vga as secondary video device? Or
virtio-gpu-pci as primary video device?
--
Andrea Bolognani / Red Hat / Virtualization
10:06 a.m.
On Fri, Sep 16, 2016 at 03:44:34PM +0200, Andrea Bolognani wrote:
On Fri, 2016-09-16 at 15:20 +0200, Pavel Hrdina wrote:
> > There is something I wanted to clarify with Laszlo: is
> > virtio-gpu-pci ever going to be usable on other architectures
> > such as x86_64? Maybe it already is? Because if that's the
> > case, we'll want to be able to choose between virtio-vga and
> > virtio-gpu-pci.
> >
> > One solution would be to keep mapping model='virtio' to
> > virtio-vga and create a new model='virtio-gpu' that maps to
> > virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
> > model='virtio'. Or something like that, I'm not married to
> > the idea, I just think it's something we should definitely
> > think about before this ends up in a release.
>
> I have some patches in my TODO branch that will rewrite the video
> device code. virtio-gpu-pci is usable also on other architectures
> but it lacks the VGA compatibility mode. In libvirt all primary
> video devices for x86 architecture have VGA mode. Currently we
> allow only QXL to be used as secondary video device and now with
> the virtio-gpu-pci it could be also used as secondary video device.
>
> The solution would be simple, there is no need to add a new video
> model 'virtio-gpu', we will use the existing model 'virtio', but
> depending on architecture and also whether it's primary or
> secondary video device we will use appropriate device.
> We already do this for QXL.
I don't know much about video devices, so forgive me if I'm
asking silly questions, but what is preventing you (on x86)
from having virtio-vga as secondary video device? Or
virtio-gpu-pci as primary video device?
You can use both as primary or secondary but it doesn't make
much sense to use only video device without VGA support on x86.
See Laszlo's explanation [1].
[1] <https://www.redhat.com/archives/libvir-list/2016-September/msg00626.html>
Pavel
10:25 a.m.
On 09/16/16 15:44, Andrea Bolognani wrote:
On Fri, 2016-09-16 at 15:20 +0200, Pavel Hrdina wrote:
>> There is something I wanted to clarify with Laszlo: is
>> virtio-gpu-pci ever going to be usable on other architectures
>> such as x86_64? Maybe it already is? Because if that's the
>> case, we'll want to be able to choose between virtio-vga and
>> virtio-gpu-pci.
>>
>> One solution would be to keep mapping model='virtio' to
>> virtio-vga and create a new model='virtio-gpu' that maps to
>> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
>> model='virtio'. Or something like that, I'm not married to
>> the idea, I just think it's something we should definitely
>> think about before this ends up in a release.
>
> I have some patches in my TODO branch that will rewrite the video
> device code. virtio-gpu-pci is usable also on other architectures
> but it lacks the VGA compatibility mode. In libvirt all primary
> video devices for x86 architecture have VGA mode. Currently we
> allow only QXL to be used as secondary video device and now with
> the virtio-gpu-pci it could be also used as secondary video device.
>
> The solution would be simple, there is no need to add a new video
> model 'virtio-gpu', we will use the existing model 'virtio', but
> depending on architecture and also whether it's primary or
> secondary video device we will use appropriate device.
> We already do this for QXL.
I don't know much about video devices, so forgive me if I'm
asking silly questions, but what is preventing you (on x86)
from having virtio-vga as secondary video device?
The "VGA compatibility" stuff in virtio-vga is not just the linear
framebuffer that lives in one of its MMIO BARs. VGA compatibility is
much larger baggage; for example, it involves hard-coded ISA IO ports.
Alex Williamson discusses VGA arbitration in the following blog post:
http://vfio.blogspot.com/2014/08/whats-deal-with-vga-arbitration.html
So the short answer is that "VGA compatibility" includes things that you
mostly want to have *exactly one* instance of, in your x86 system. Zero
instances of those things, and you might lose compatibility with some
software; more than one instance of that stuff, and things get really
messy with arbitration (hard-coded IO ports and MMIO ranges).
So, even in the physical word, a multi-graphics-card x86 workstation
usually has one primary VGA card (nowadays likely as an integrated
device), carrying the legacy baggage; and then a number of secondary
GPUs (that have none of that baggage).
Or
virtio-gpu-pci as primary video device?
I described this earlier -- virtio-gpu-pci is more limited than
virtio-vga as a primary graphics card, so wherever you can go with
virtio-vga as primary, you'll do that. In aarch64/KVM guests however,
virtio-vga is not an option, and the more limited (as primary)
virtio-gpu-pci card is still better (much better) than nothing.
Thanks
Laszlo
9:59 a.m.
On 09/16/16 15:20, Pavel Hrdina wrote:
On Fri, Sep 16, 2016 at 03:06:18PM +0200, Andrea Bolognani wrote:
> On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
>> On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
>>> Most of QEMU's PCI display device models, such as:
>>
>> Pushed, thanks.
>
> Ouch, you were too fast! ;)
>
> There is something I wanted to clarify with Laszlo: is
> virtio-gpu-pci ever going to be usable on other architectures
> such as x86_64? Maybe it already is? Because if that's the
> case, we'll want to be able to choose between virtio-vga and
> virtio-gpu-pci.
>
> One solution would be to keep mapping model='virtio' to
> virtio-vga and create a new model='virtio-gpu' that maps to
> virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
> model='virtio'. Or something like that, I'm not married to
> the idea, I just think it's something we should definitely
> think about before this ends up in a release.
I have some patches in my TODO branch that will rewrite the video
device code. virtio-gpu-pci is usable also on other architectures
but it lacks the VGA compatibility mode. In libvirt all primary
video devices for x86 architecture have VGA mode.
Indeed, and that's a good thing. "virt" needs an exception because the
framebuffer is "exceptionally" broken on aarch64/KVM :)
Currently we
allow only QXL to be used as secondary video device
Yeah, I noticed that, and I was wondering if virtio-gpu-pci would
qualify at some point.
and now with
the virtio-gpu-pci it could be also used as secondary video device.
The solution would be simple, there is no need to add a new video
model 'virtio-gpu', we will use the existing model 'virtio', but
depending on architecture and also whether it's primary or
secondary video device we will use appropriate device.
Sounds good to me (and the patch at hand should be compatible with the
idea). I'll have to read the rest of the thread to see if Andrea is okay
with the idea :)
Thanks!
Laszlo
We already do this for QXL.
Pavel
10:44 a.m.
On Fri, 2016-09-16 at 16:59 +0200, Laszlo Ersek wrote:
> The solution would be simple, there is no need to add a new
video
> model 'virtio-gpu', we will use the existing model 'virtio', but
> depending on architecture and also whether it's primary or
> secondary video device we will use appropriate device.
Sounds good to me (and the patch at hand should be compatible with the
idea). I'll have to read the rest of the thread to see if Andrea is okay
with the idea :)
After reading through the entire thread and absorbing the
detailed explanations contained therein (thanks everyone!)
I'm okay with the patch as pushed :)
--
Andrea Bolognani / Red Hat / Virtualization
9:53 a.m.
On 09/16/16 15:06, Andrea Bolognani wrote:
On Fri, 2016-09-16 at 14:43 +0200, Pavel Hrdina wrote:
> On Fri, Sep 16, 2016 at 09:30:23AM +0200, Laszlo Ersek wrote:
>> Most of QEMU's PCI display device models, such as:
>
> Pushed, thanks.
Thanks Pavel!
Ouch, you were too fast! ;)
There is something I wanted to clarify with Laszlo: is
virtio-gpu-pci ever going to be usable on other architectures
such as x86_64? Maybe it already is? Because if that's the
case, we'll want to be able to choose between virtio-vga and
virtio-gpu-pci.
One solution would be to keep mapping model='virtio' to
virtio-vga and create a new model='virtio-gpu' that maps to
virtio-gpu-pci, then forbid aarch64 mach-virt guests to use
model='virtio'. Or something like that, I'm not married to
the idea, I just think it's something we should definitely
think about before this ends up in a release.
I considered this (I think we may have even discussed something like
this downstream, with Marc-André et al... I'm quite vague on it now),
but being this precise about it in the domain XML doesn't bring a lot of
benefits.
Namely, the simple truth is, wherever virtio-vga works, you want
virtio-vga. The VGA compat framebuffer is beneficial -- as its name says
-- for compatibility reasons, for boot firmware and for unaccelerated (=
default) guest OS drivers. For example, in x86_64 guests, you likely
never explicitly want virtio-gpu-pci over virtio-vga, because the UEFI
Windows (8, 10) boot loaders will never work with the former, but they
(and the runtime OSes themselves) nicely work with virtio-vga, due to
the compat framebuffer.
So, really, virtio-vga is the sane default, and the only reason to ever
want virtio-gpu-pci -- as a primary graphics card -- is if virtio-vga is
unusable for architectural reasons.
Thanks
Laszlo
3080
days inactive
3080
days old
12 comments
4 participants
participants (4)
-
Andrea Bolognani -
Laszlo Ersek -
Martin Kletzander -
Pavel Hrdina