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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux