libvirt/tests/qemuxml2xmloutdata/aarch64-video-default.aarch64-latest.xml

44 lines
1.5 KiB
XML
Raw Normal View History

qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<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>
<boot dev='hd'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
</os>
<features>
<gic version='2'/>
</features>
<cpu mode='custom' match='exact' check='none'>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<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>/usr/bin/qemu-system-aarch64</emulator>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='pcie-root-port'>
<model name='pcie-root-port'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<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='pcie-root-port'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<target chassis='2' port='0x9'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
</controller>
<graphics type='vnc' port='-1' autoport='yes'>
<listen type='address'/>
</graphics>
<audio id='1' type='none'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
<video>
<model type='virtio' heads='1' primary='yes'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
qemu: map "virtio" video model to "virt" machtype correctly (arm/aarch64) 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@redhat.com> Cc: Drew Jones <drjones@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Martin Kletzander <mkletzan@redhat.com>
2016-09-16 07:30:23 +00:00
</video>
</devices>
</domain>