aboutsummaryrefslogtreecommitdiff
path: root/hw/display/ramfb.c
AgeCommit message (Collapse)Author
2020-05-18ramfb: fix size calculationGerd Hoffmann
size calculation isn't correct with guest-supplied stride, the last display line isn't accounted for correctly. For the typical case of stride > linesize (add padding) we error on the safe side (calculated size is larger than actual size). With stride < linesize (scanlines overlap) the calculated size is smaller than the actual size though so our guest memory mapping might end up being too small. While being at it also fix ramfb_create_display_surface to use hwaddr for the parameters. That way all calculation are done with hwaddr type and we can't get funny effects from type castings. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-7-kraxel@redhat.com
2020-05-18ramfb: add sanity checks to ramfb_create_display_surfaceGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-6-kraxel@redhat.com
2020-05-18ramfb: don't update RAMFBState on errorsGerd Hoffmann
Store width & height & surface in local variables. Update RAMFBState with the new values only in case the ramfb_create_display_surface() call succeeds. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-5-kraxel@redhat.com
2020-05-18ramfb: drop leftover debug messageGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-4-kraxel@redhat.com
2020-05-18Revert "hw/display/ramfb: lock guest resolution after it's set"Gerd Hoffmann
This reverts commit a9e0cb67b7f4c485755659f9b764c38b5f970de4. This breaks OVMF. Reproducer: Just hit 'ESC' at early boot to enter firmware setup. OVMF wants switch from (default) 800x600 to 640x480 for that, and this patch blocks it. Cc: Hou Qiming <hqm03ster@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-3-kraxel@redhat.com
2020-05-18Revert "hw/display/ramfb: initialize fw-config space with xres/ yres"Gerd Hoffmann
This reverts commit f79081b4b71b72640bedd40a7cd76f864c8287f1. Patch has broken byteorder handling: RAMFBCfg fields are in bigendian byteorder, the reset function doesn't care so native byteorder is used instead. Given this went unnoticed so far the feature is obviously unused, so just revert the patch. Cc: Hou Qiming <hqm03ster@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20200429115236.28709-2-kraxel@redhat.com
2020-02-20Let cpu_[physical]_memory() calls pass a boolean 'is_write' argumentPhilippe Mathieu-Daudé
Use an explicit boolean type. This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Clean up inclusion of sysemu/sysemu.hMarkus Armbruster
In my "build everything" tree, changing sysemu/sysemu.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Almost a third of its inclusions are actually superfluous. Delete them. Downgrade two more to qapi/qapi-types-run-state.h, and move one from char/serial.h to char/serial.c. hw/semihosting/config.c, monitor/monitor.c, qdev-monitor.c, and stubs/semihost.c define variables declared in sysemu/sysemu.h without including it. The compiler is cool with that, but include it anyway. This doesn't reduce actual use much, as it's still included into widely included headers. The next commit will tackle that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-27-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-08-16Include sysemu/reset.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/reset.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The main culprit is hw/hw.h, which supposedly includes it for convenience. Include sysemu/reset.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-9-armbru@redhat.com>
2019-05-24hw/display/ramfb: initialize fw-config space with xres/ yresHou Qiming
If xres / yres were specified in QEMU command line, write them as an initial resolution to the fw-config space on guest reset, which a later BIOS / OVMF patch can take advantage of. Signed-off-by: HOU Qiming <hqm03ster@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-id: 20190513115731.17588-4-marcel.apfelbaum@gmail.com [fixed malformed patch] Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-24hw/display/ramfb: lock guest resolution after it's setHou Qiming
Only allow one resolution change per guest boot, which prevents a crash when the guest writes garbage to the configuration space (e.g. when rebooting). Signed-off-by: HOU Qiming <hqm03ster@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-id: 20190513115731.17588-3-marcel.apfelbaum@gmail.com [fixed malformed patch] Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-05-24hw/display/ramfb: fix guest memory un-mappingHou Qiming
Pulled back the `qemu_create_displaysurface_guestmem` function to create the display surface so that the guest memory gets properly unmapped. Signed-off-by: HOU Qiming <hqm03ster@gmail.com> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Message-id: 20190513115731.17588-2-marcel.apfelbaum@gmail.com [rename the new functions and use QEMU coding style] Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-07-02ramfb: enable vgabiosGerd Hoffmann
Add vgabios binary to fw_cfg vgaroms. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-06-26ramfb: fix overflowGerd Hoffmann
> CID 1393621: (OVERFLOW_BEFORE_WIDEN) > Potentially overflowing expression "stride * s->height" with type "unsigned > int" (32 bits, unsigned) is evaluated using +32-bit arithmetic, and then used > in a context that expects an expression of type "hwaddr" (64 bits, unsigned). Fix by changing stride from uint32_t to hwaddr. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20180626083120.19515-1-kraxel@redhat.com
2018-06-18hw/display: add ramfb, a simple boot framebuffer living in guest ramGerd Hoffmann
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-16 05:16:54 +0000