On Mon, Aug 25, 2014 at 2:21 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> 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?
Why not use Private->Variant, rather than 'IsQxl'?
-Jordan
> -------------------------
> 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
------------------------------------------------------------------------------
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
