Add new virtio-gpu devices with a "vhost-user" property. The
associated vhost-user backend is used to handle the virtio rings and
provide rendering results thanks to the vhost-user-gpu protocol.
Example usage:
-object vhost-user-backend,id=vug,cmd="./vhost-user-gpu"
-device vhost-user-vga,vhost-user=vug
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20190524130946.31736-10-marcandre.lureau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a base class that is common to virtio-gpu and vhost-user-gpu
devices.
The VirtIOGPUBase base class provides common functionalities necessary
for both virtio-gpu and vhost-user-gpu:
- common configuration (max-outputs, initial resolution, flags)
- virtio device initialization, including queue setup
- device pre-conditions checks (iommu)
- migration blocker
- virtio device callbacks
- hooking up to qemu display subsystem
- a few common helper functions to reset the device, retrieve display
informations
- a class callback to unblock the rendering (for GL updates)
What is left to the virtio-gpu subdevice to take care of, in short,
are all the virtio queues handling, command processing and migration.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20190524130946.31736-8-marcandre.lureau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
guests running on these and the PMON2000 firmware of the fulong2e
expect this to be available. Fortunately these are very similar chips
so they can be mostly emulated in the same device model. This patch
adds basic emulation of these ATI VGA chips.
While this is incomplete and currently only enough to run the MIPS
firmware and get framebuffer output with Linux, it allows the fulong2e
board to work more like the real hardware and having it in QEMU in
this state provides a way to experiment with it and allows others to
contribute to improve it. It is compiled for all archs but only the
fulong2e (which currently has no display output at all) is set to use
it by default (in a separate patch).
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Tested-by: Andrew Randrianasulu <randrianasulu@gmail.com>
Tested-by: Howard Spoelstra <hsp.cat7@gmail.com>
Message-id: 0b1b7c22873a6e37627261b04fb687412b25ff4f.1552152100.git.balaton@eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In downstream distros like RHEL we'd like to disable some of the "legacy"
devices of QEMU. The ISA version of the Cirrus VGA device is one of these
legacy devices. So let's make the build process a little bit more flexible
here by putting the Cirrus ISA code into a separate file which is only
included if both, CONFIG_VGA_CIRRUS and CONFIG_VGA_ISA are set.
Note that this disables "isa-cirrus-vga" for the ppc-softmmu and the
alpha-softmmu target since CONFIG_VGA_ISA is not set there. But I think
this is OK since these targets are only interested in the PCI variant
anyway.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1539339106-32427-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
EDID is a metadata format to describe monitors. On physical hardware
the monitor has an eeprom with that data block which can be read over
i2c bus.
On a linux system you can usually find the EDID data block in
/sys/class/drm/$card/$connector/edid. xorg ships a edid-decode utility
which you can use to turn the blob into readable form.
I think it would be a good idea to use EDID for virtual displays too.
Needs changes in both qemu and guest kms drivers. This patch is the
first step, it adds an generator for EDID blobs to qemu. Comes with a
qemu-edid test tool included.
With EDID we can pass more information to the guest. Names and serial
numbers, so the guests display configuration has no boring "Unknown
Monitor". List of video modes. Display resolution, pretty important
in case we want add HiDPI support some day.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20180925075646.25114-2-kraxel@redhat.com
According to the ramfb_setup() function, the ramfb device needs fw_cfg
with DMA, so we should also only compile and link it into those targets
which support it, to avoid that the device shows up on systems where it
can not be used at all (e.g. s390x).
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-id: 1534786083-26559-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The boot framebuffer is expected to be configured by the firmware, so it
uses fw_cfg as interface. Initialization goes as follows:
(1) Check whenever etc/ramfb is present.
(2) Allocate framebuffer from RAM.
(3) Fill struct RAMFBCfg, write it to etc/ramfb.
Done. You can write stuff to the framebuffer now, and it should appear
automagically on the screen.
Note that this isn't very efficient because it does a full display
update on each refresh. No dirty tracking. Dirty tracking would have
to be active for the whole ram slot, so that wouldn't be very efficient
either. For a boot display which is active for a short time only this
isn't a big deal. As permanent guest display something better should be
used (if possible).
This is the ramfb core code. Some windup is needed for display devices
which want have a ramfb boot display.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Message-id: 20180613122948.18149-2-kraxel@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is only half of the work, because the proxy devices (virtio-*-pci,
virtio-*-ccw, etc.) are still included unconditionally. It is still a
move in the right direction.
Based-on: <20180522194943.24871-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After writing up the virtual mdev device emulating a display supporting
the bochs vbe dispi interface (mbochs.ko) and seeing how simple it
actually is I've figured that would be useful for qemu too.
So, here it is, -device bochs-display. It is basically -device VGA
without legacy vga emulation. PCI bar 0 is the framebuffer, PCI bar 2
is mmio with the registers. The vga registers are simply not there
though, neither in the legacy ioport location nor in the mmio bar.
Consequently it is PCI class DISPLAY_OTHER not DISPLAY_VGA.
So there is no text mode emulation, no weird video modes (planar,
256color palette), no memory window at 0xa0000. Just a linear
framebuffer in the pci memory bar. And the amount of code to emulate
this (and therefore the attack surface) is an order of magnitude smaller
when compared to vga emulation.
Compatibility wise it works with OVMF (latest git master).
The bochs-drm.ko linux kernel module can handle it just fine too.
So UEFI guests should not see any functional difference to VGA.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20180522165058.15404-4-kraxel@redhat.com
x_keymap.o is common to the SDL and GTK+ modules, and it causes the
QEMU binary to link to the X11 libraries. Add it separately to the
modules to keep the main QEMU binary smaller.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1526560782-18732-1-git-send-email-pbonzini@redhat.com
[ kraxel: fix lm32 target build (milkymist-tmu2) ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This adds support for emulating the Silicon Image SII9022 DVI/HDMI
bridge. It's not very clever right now, it just acknowledges
the switch into DDC I2C mode and back. Combining this with the
existing DDC I2C emulation gives the right behavior on the Versatile
Express emulation passing through the QEMU EDID to the emulated
platform.
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Message-id: 20180227104903.21353-5-linus.walleij@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: explictly reset ddc_req/ddc_skip_finish/ddc]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add virglrenderer library detection. Add 3d mode to virtio-gpu,
wire up virglrenderer library. When in 3d mode render using the
new context management and texture scanout callbacks.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
This patch adds a virtio-vga device. It is simliar to virtio-gpu-pci,
but it also adds in vga compatibility, so guests without native
virtio-gpu support can drive the device in vga mode. It is compatible
with stdvga.
Written by Dave Airlie and Gerd Hoffmann.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds virtio-gpu-pci, which is the pci proxy for the virtio
gpu device. With this patch in place virtio-gpu is functional. You
need a linux guest with a virtio-gpu driver though, and output will
appear pretty late in boot, once the kernel initialized drm and fbcon.
Written by Dave Airlie and Gerd Hoffmann.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds the core code for virtio gpu emulation,
covering 2d support.
Written by Dave Airlie and Gerd Hoffmann.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is better and prepares for the next patch. When we copy
libs_softmmu's value into LIBS with a := assignment, we cannot
anymore modify libs_softmmu in the Makefiles.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Rename config option from "glx" to "opengl", glx will not be the only
option for opengl in near future. Also switch over to pkg-config for
opengl support detection.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
