qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "seabios@seabios.org" <seabios@seabios.org>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU
Date: Wed, 17 Feb 2016 06:49:56 -0700	[thread overview]
Message-ID: <20160217064956.626fb7a0@t450s.home> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F7B6902@SHSMSX101.ccr.corp.intel.com>

On Wed, 17 Feb 2016 11:09:49 +0000
"Tian, Kevin" <kevin.tian@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.

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,

Alex

  reply	other threads:[~2016-02-17 13:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 21:39 [Qemu-devel] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU Alex Williamson
2016-02-17 11:09 ` Tian, Kevin
2016-02-17 13:49   ` Alex Williamson [this message]
2016-02-18  6:43     ` Tian, Kevin
2016-02-23 15:22 ` Kevin O'Connor
2016-05-10 15:19   ` Alex Williamson
2016-05-11 10:07     ` Igor Mammedov
2016-05-11 15:19     ` Kevin O'Connor
2016-05-11 18:39       ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160217064956.626fb7a0@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=allen.m.kay@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).