On 02/03/14 09:40, Gerd Hoffmann wrote:
> Hi,
>
>> But, indeed, that's my problem exactly. I did look into the qemu source
>> (and I did notice VBE_DISPI_INDEX_VIDEO_MEMORY_64K), and there are about
>> five device and/or global properties (from which libvirt uses at least
>> two) that mess around with sizes related to video ram.
>
> ram_size (bytes)
> ram_size_mb (megabytes)
> Size of pci bar 0.
>
> vgaram_mb (megabytes)
> Size of the vga compat framebuffer.
>
>> Also there's bar 1 ("vram32_size"?) which is supposed to hold... What
>> precisely? Very confusing.
>
> vram_size (bytes)
> vram_size_mb (megabytes)
> Size of pci bar 1.
>
> Guest driver can store image data there for drawing operations. Not
> relevant for firmware framebuffer support.
>
> For completeness:
>
> vram64_size_mb (megabytes)
> Size of pci bar 5. It's vram too (same as bar 1), but a 64bit bar
> so it can be mapped above 4g. Will only show up if you configure
> vram64_size_mb being larger than vram_size_mb.
>
>> So, I understand VBE_DISPI_INDEX_VIDEO_MEMORY_64K is what I should use
>> for querying. What is the *one* qemu option that I need to use for
>> setting? I'd like to put the right hint in the commit message.
>
> It's vgaram_mb, for both stdvga and qxl (and IIRC vmware too).
>
> But on qxl you have the additional constrain that vgaram_mb can't cover
> more than 50% of the bar0 size, which is 64mb by default. So if you
> need more than 32mb you have so set both vgaram_mb and ram_size_mb.
Perfect, thank you for the explanation.
... Also, I think I won't (have to) introduce a new (long-term) variable
/ field for the available framebuffer size. The current call tree is:
QemuVideoControllerDriverStart() [OvmfPkg/QemuVideoDxe/Driver.c]
if BOCHS or BOCHS_MMIO:
BochsRead(VBE_DISPI_INDEX_ID) [OvmfPkg/QemuVideoDxe/Driver.c]
/* ... */
if BOCHS or BOCHS_MMIO:
QemuVideoBochsModeSetup() [OvmfPkg/QemuVideoDxe/Initialize.c]
/* filter & populate modes */
I could introduce a new local in QemuVideoControllerDriverStart():
(#1)
QemuVideoControllerDriverStart()
if BOCHS or BOCHS_MMIO:
BochsRead(VBE_DISPI_INDEX_ID)
Avail = BochsRead(VBE_DISPI_INDEX_VIDEO_MEMORY_64K) // new
/* ... */
if BOCHS or BOCHS_MMIO:
QemuVideoBochsModeSetup(Avail) // pass it in
/* filter & populate modes */
or else push it down in QemuVideoBochsModeSetup():
(#2)
QemuVideoControllerDriverStart()
if BOCHS or BOCHS_MMIO:
BochsRead(VBE_DISPI_INDEX_ID)
/* ... */
if BOCHS or BOCHS_MMIO:
QemuVideoBochsModeSetup()
Avail = BochsRead(VBE_DISPI_INDEX_VIDEO_MEMORY_64K) // just grab
// it here
/* filter & populate modes */
I prefer the second, because it wouldn't clutter the
QemuVideoControllerDriverStart() function with more variant-specific
stuff. In addition, BochsRead() is an extern function
(OvmfPkg/QemuVideoDxe/Qemu.h), so I could call it from
QemuVideoBochsModeSetup(). Basically, I could keep the code structure
visible in v1 5/6, just change how "AvailableFbSize" is computed.
Would you accept this in v2?
Thank you!
Laszlo
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
