> From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > Sent: Wednesday, February 17, 2016 9:50 PM > > On Wed, 17 Feb 2016 11:09:49 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> 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. Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
