On 08/25/14 14:43, Gerd Hoffmann wrote:
> Hi,
>
>> The current calculation is correct for stdvga, because on stdvga the value
>> returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K, ie. the full video RAM, is
>> usable for drawing.
>
> Value returned by VBE_DISPI_INDEX_VIDEO_MEMORY_64K being wrong is a qemu
> bug. We have releases with the bug in the wild though, so adding this
> as (temporary?) workaround is sensible IMO. The comment should be
> updated saying so though.
Thanks for the review!
If the workaround is stable in your opinion (ie. it can be relied upon
even after the qemu problem with VBE_DISPI_INDEX_VIDEO_MEMORY_64K is
fixed), then I'd probably leave it in, even in the long term.
Jordan, is it enough if I only reword the commit message below, or do
you want me to resubmit the patch?
-------------------------
OvmfPkg: QemuVideoDxe: work around misreported QXL framebuffer size
When setting up the list of GOP modes offered on QEMU's stdvga ("VGA")
and QXL ("qxl-vga") video devices, QemuVideoBochsModeSetup() filters
those modes against the available framebuffer size. (Refer to SVN
r15288 / git commit ec88061e.)
The VBE_DISPI_INDEX_VIDEO_MEMORY_64K register of both stdvga and QXL is
supposed to report the size of the drawable, VGA-compatibility
framebuffer. Instead, up to and including qemu-2.1, this register
actually reports the full video RAM (PCI BAR 0) size.
In case of stdvga, this happens to be correct, because on that card the
full PCI BAR 0 is usable for drawing; there is no difference between
"drawable framebuffer size" and "video RAM (PCI BAR 0) size".
However, on the QXL card, only an initial portion of the video RAM is
suitable for drawing, as compatibility framebuffer; and the value
currently reported by VBE_DISPI_INDEX_VIDEO_MEMORY_64K overshoots the
valid size. Beyond the drawable range, the video RAM contains buffers
and structures for the QXL guest-host protocol.
Luckily, the size of the drawable QXL framebuffer can also be read from
a register in the QXL ROM BAR (PCI BAR 2), so let's retrieve it from
there.
Without this fix, OVMF offers too large resolutions on the QXL card (up
to the full size of the video RAM). If a GOP client selects such a
resolution and draws into the video RAM past the compatibility segment,
then the guest corrupts its communication structures (which is invalid
guest behavior).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <ler...@redhat.com>
-------------------------
Thanks,
Laszlo
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
