[SeaBIOS] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU

Tian, Kevin kevin.tian at intel.com
Thu Feb 18 07:43:44 CET 2016

> From: Alex Williamson [mailto:alex.williamson at redhat.com]
> Sent: Wednesday, February 17, 2016 9:50 PM
> On Wed, 17 Feb 2016 11:09:49 +0000
> "Tian, Kevin" <kevin.tian at intel.com> wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, February 17, 2016 5:39 AM
> > >
> > > QEMU provides two fw_cfg files to support IGD.  The first holds the
> > > OpRegion data which holds the Video BIOS Table (VBT).  This needs to
> > > be copied into reserved memory and the address stored in the ASL
> > > Storage register of the device at 0xFC offset in PCI config space.
> > > The OpRegion is generally 8KB.  This file is named "etc/igd-opregion".
> > >
> > > The second file tells us the required size of the stolen memory space
> > > for the device.  This is a dummy file, it has no backing so we only
> > > allocate the space without copying anything into it.  This space
> > > requires 1MB alignment and is generally either 1MB or 2MB, depending
> > > on the hardware config.  If the user has opted in QEMU to expose
> > > additional stolen memory beyond the GTT (GGMS), the GMS may add an
> > > additional 32MB to 512MB.  The base address of the reserved memory
> > > allocated for this is written back to the Base Data of Stolen Memory
> > > register (BDSM) at PCI config offset 0x5C on the device.  This file is
> > > named "etc/igd-bdsm".
> >
> > What would happen if guest tries to access this range while there is
> > no actual memory behind? Isn't it more clear to hide stolen memory
> > at all instead of reporting a dummy range?
> It's a fw_cfg file, it's not exposed to the guest, the purpose is to
> convey the size of stolen memory, which the BIOS then allocates as
> reserved memory and writes back to the BDSM register.  It would be more
> clean to ignore stolen memory, but in cases where we need the vBIOS,
> such as laptops, where my LCD panel won't turn on without it, we don't
> have that luxury.  The vBIOS programs the device to use stolen memory,
> at least 1MB, I assume for GTT purposes, and makes use of that for VESA
> modes.  So, we need the vBIOS to support laptop panels, the vBIOS needs
> stolen memory for GTT space, therefore we need to provide some stolen
> memory.

Thanks for explaining the rationale. It's a bit surprise to me but anyway
since you do observe the effect. Allen might help confirm whether your
assumption makes sense. :-)

> This support is enabled in QEMU by using a vBIOS, I assume vGPUs won't
> expose a ROM BAR and therefore won't enable this.  Additionally for
> BDW/SKL+ (gen8+) GPUs, if the user specifies rombar=0 then all of this
> is disabled, including the hostbridge and ISA bridge manipulation in
> order to support UPT mode.  Thanks,

Correct. vGPU doesn't use a host vBIOS. We just leverage existing
Seabios for early booting.


More information about the SeaBIOS mailing list